21 ms·

Be Aware of the Makefile Effect

• kazinator 2y ago
  At first I couldn't understand what this article is saying. Then, .SECONDEXPANSION: kicked in!
• rpcope1 2y ago
  I feel this way every time with webpack, npm and babel.
• Over2Chars 2y ago
  A clever point, worth discussing
• travisgriggs 2y ago
  It’s like a variant of Pournelles Law.
  • fargle 2y ago
    i think you got the wrong eponymous law, pournelle's iron law of bureaucracy (which i see happening all the time, btw.) has nothing to do with this issue.
• donatj 2y ago
  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.
  • bboygravity 2y ago
    How do you know what is and isn't related if nothing is documented? Trial and error? Well have fun with that :p
    • donatj 2y ago
      Exactly. Bonus points if the person who started the project moved on and you have to be the one to build and maintain it.
    • rmgk 2y ago
      You find the first part in your stack that is documented (e.g., make is documented, even if your makefile is not) and use that documentation to understand the undocumented part. You then write down your findings for the next person. If you don’t have enough time, write down whatever pieces you understood, and write down what parts “seem to work, but you don’t understand“ to help make progress towards better documentation. If you put the documentation as comments into the file, this can make copy&pasting working examples into a reasonably solid process.
    • marcosdumay 2y ago
      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.
• ruuda 2y ago
  I think LaTeX is the poster child of this. Nobody writes a LaTeX preamble from scratch, you always copy your previous document and tweak it.
  • __mharrison__ 2y ago
    I use Typst now instead and wrote the "preamble" from scratch. (Because Typst is that much less annoying than LaTeX)
  • sandbach 2y ago
    Don't do that! If you're always using the same preamble, you should turn it into a .sty file. Then the preamble of new documents is just \usepackage{myessay}
    • aragilar 2y ago
      I did that, then I needed to tweak things so I added options, then I needed to use the package somewhere that needed to be self-contained, so I started copy-pasting ;). I've done similar things with makefiles, tox configs, linter settings (all of which started from an initial version I wrote from scratch). I suspect the real reason this effect exists is because there's copy-pasting is the best way to solve the problem, due to a varying mix of: there being no way of managing the dependencies, needing to avoid (unmanaged) dependencies (i.e. vendoring is the same, only we have a tool managing it), the file (or its contents) needing to exist there specifically (e.g. the various CI locations) and no real agreement on what template/templating tool to use (and a template is just as likely to include useless junk). Copy-pasting is viewed as a one-time cost, and the thing copy-pasted isn't expected to change all that much.
      • ttyprintk 2y ago
        Definitely true for linting. Nothing unlike a linter solves the problems we want the linter to solve.
    • fph 2y ago
      Then you make a change to myessay.sty and suddenly four of your old files stop compiling.
• ratmeadow 2y ago
  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 have to learn all this just to build the app? Devs expect it to "just work" and if there are complexities then another team (AKA my role) deals with that. As a result, any time devs interact with the system, there's a high motivation to copy from the last working setup and move on with their day to the "real" work. The best solution I see is meet the devs halfway. Provide them with tooling that is appropriate simple/complex for the task, provide documentation, minimise belief in "magic". Tools like Make kinda fail here because they are too complex and black-box-like.
  • exitb 2y ago
    The office coffee machine is not „set and forget”, but you wouldn’t expect the entire responsibility for it’s maintenance to be evenly distributed between all people that use it. Similarly, CI needs ownership and having it fall on the last developer that attempted to use it is not an efficient way of working.
  • nicoburns 2y ago
    For me the big problems with CI setups tend to be: - They're often slow - They're often proprietary - They're often dealing with secrets which limits who can work on them - You generally can't run them locally So the feedback cycle for working on them is incredibly long. And working on them is therefore a massive pain.
    • sharkjacobs 2y ago
      > You generally can't run them locally I recognize that this is such a disincentive for me taking the initiative to fiddle with and learn about anything like this
      • vintermann 2y ago
• fithisux 2y ago
  Alias, cmake effect.
  • chikere232 2y ago
    Let's keep "cmake effect" for "trying your best to not have to touch the language and repeatedly looking for something else whenever you do" It's a very microsoft feeling pile of crap
• szarnyasg 2y ago
  I have observed the Makefile effect many times for LaTeX documents. Most researchers I worked with had a LaTeX file full of macros that they have been carrying from project to project for years. These were often inherited from more senior researchers, and were hammered into heavily-modified forks of article templates used in their field or thesis templates used at their institution.
  • wjholden 2y ago
    This is a great example of an instance of this "Makefile effect" with a possible solution: use Markdown and Pandoc where possible. This won't work in every situation, but sometimes one can compose a basic Beamer presentation or LaTeX paper quickly using largely simple TeX and the same Markdown syntax you already know from GitHub and Reddit.
    • kergonath 2y ago
      > use Markdown and Pandoc where possible. That won’t solve any problem that LaTeX macros solve. Boilerplate in LaTeX has 2 purposes. The first is to factor frequently-used complex notations. To do this in Markdown you’d need to bolt on a macro preprocessor on top of Markdown. The second one is to fine-tune typography and layout details (tables are a big offender). This is something that simply cannot be done in Markdown. A table is a table and if you don’t like the style (which is most of the time inadequate) then there is no solution.
    • gardenerik 2y ago
      A much better solution would be to use Typst, but that still might not work in all situations.
• leoc 2y ago
  Old IBM mainframe scripting in JCL https://en.wikipedia.org/wiki/Job_Control_Language https://en.wikipedia.org/wiki/Job_Control_Language (so "OS JCL" now, I suppose) used to have a terrible reputation for this, but I've never actually touched the stuff myself.
• baobun 2y ago
  Good points in general. On the other hand, there are cases where (beneficial/desired) verbosity prompts copy-paste and tweaking - not due to complexity but from some form of scale or size of the input. In many cases this is a sign of something that should be dynamic data (put it in a db instead of conf) but that's not always the case and worth the tradeoff in the moment.
• lazystar 2y ago
  amazon's internal build tool experiences this same phenomena. engineers are hired based on their leetcode ability; which means the average engineer has gaps in their infrastructure and config tool knowledge/skillset. until the industrys hiring practices shift, this trend will continue.
  • marxisttemp 2y ago
    As an undergrad, I did group projects with people who quite literally could not compile and run any actual project on their system outside of a pre-packaged classwork assignment, who essentially could not code at all outside of data structure and algorithm problem sets, who got Google internships the next semester. But they were definitely brighter than I when it came to such problem sets. I suppose we need both sorts of engineer to make great things
• malkia 2y ago
  or ahem... CMake
• mattbillenstein 2y ago
  I think Makefile is maybe the wrong analogy - the problem with most people and makefiles is they write so few of them, the general idea of what make does is at hand, but the muscle memory of how to do it from scratch is not. But, point taken - I've seen so much code copy-pasta'd from the web, there will be like a bunch of dead stuff in it that's actually not used. A good practice here is to keep deleting stuff until you break it, then put whatever that was back... And delete as much as possible - certainly everything you're not using at the moment.
  • sumanthvepa 2y ago
    This is exactly the problem I face with many tools, Makefiles, KVM setups, docker configurations, CI/CD pipelines. My solution so far has been to create a separate repository with all my notes, shell script example programs etc, for these tool, libraries or frameworks. Every time I have to use these tools, I refer to my notes to refresh my memory, and if I learn something new in the process, I update the notes. I can even point an LLM at it now and ask it questions. The repository is personal, and contains info on tools that are publicly available. I keep organisation specific knowledge in a similar but separate repo, which I discard when my tenure with a client or employer ends.
    • parasti 2y ago
      What if your client comes back? On a more practical note, what structure, formats and tools do you use that enable you to feed it to an LLM?
      • sumanthvepa 2y ago
        I'm usually contractually obligated to destroy all client IP that I may posses at the end of an engagement. My contracts usually specify that I will retain engagement specific information for a period of six months beyond the end of the contract. If they come back within that time, then I'll have prior context. Otherwise it's gone. Occasionally, a client does come back after a year or two, but most of the knowledge would have been obsolete and outdated anyway. As for LLMs. I have a couple of python scripts that concatenate files in the repo into a context that I pass to Google's Gemini API or Google AI studio, mostly the latter. It can get expensive in some situations. I don't usually load the whole repository. And I keep the chat context around so I can keep asking question around the same topic.
• teo_zero 2y ago
  > the tool (or system) is too complicated (or annoying) to use from scratch. Or boring: some systems require boilerplate with no added value. It's normal to copy & paste from previous works. Makefiles are a good example. Every makefile author must write their own functionally identical "clean" target. Shouldn't there be an implicit default? C is not immune, either. How many bits of interesting information do you spot in the following excerpt? #include <stdio.h> int main(int argc, char **argv) { printf("Hello\n"); return 0; } The printf alone is the real payload, the rest conveys no information. (Suggestion for compiler authors: since the programs that include stdio.h outnumber those that don't, wouldn't it be saner for a compiler to automatically do it for us, and accept a flag to not do it in those rare cases where we want to deviate?)
  • skirge 2y ago
    more implicit behaviors more surprises, like security bugs because default functionality or conversions happen
  • oguz-ismail 2y ago
    > wouldn't it be saner for a compiler to automatically do it for us no
  • lucianbr 2y ago
    > since the programs that include stdio.h outnumber those that don't I don't think that is true. There is a lot of embedded systems C out there, plus there are a lot of files in most projects, and include is per file not per project. The project might use stdio in a few files, and not use it in many others.
  • deleted 2y ago
    [deleted]
  • brabel 2y ago
    > The printf alone is the real payload, the rest conveys no information. What are you talking about? Every line is important. #include <stdio.h> This means you need IO in your program. C is a general purpose language , it shouldn't include that unless asked for. You could claim it should include stuff by default, but that would go completely against what C stands for. Code shouldn't have to depend on knowing which flags you need to use to compile successfully (at least not in general like this). int main(int argc, char** argv) Every program requires a main function. Scripting languages pretend they don't, but they just wrap all top-level code in one. Having that be explicit, again, is important for a low level language like C. By the way, the C standard lets you declare it in a simplified manner: int main(void) Let's ignore the braces as you could just place them on the same line. printf("Hello\n"); You could just use `puts` here, but apart from that, yeah that's the main payload, cool. return 0; The C standard actually makes this line optional. Funny but I guess it addresses your complaint that "common stuff" perhaps should not be spelled out all the time? So, here is the actual minimalist Hello world: #include <stdio.h> int main(void) { puts("Hello world\n"); }
• dirkt 2y ago
  Same with programming: You just copy some old code and modify it, if you have something lying around. Same with frameworks (Angular, Spring Boot, ...). The tools even come with templates to generate new boilerplate for people who don't have existing ones somewhere.
• Papirola 2y ago
  I call it the yoghurt effect.
  • fargle 2y ago
    i'll bite. care to expand? is this a riff on copy-pasta or spaghetti code or what?
• __mharrison__ 2y ago
  Setup.py, cron, makefile, bash scripts, GitHub actions, and devcontainers all had this effect... Until AI came around. Now AI does a great job of getting you 90-100% of the way there.
• mianos 2y ago
  I have an alternate theory: about 10% of developers can actually start something from scratch because they truly understand how things work (not that they always do it, but they could if needed). Another 40% can get the daily job done by copying and pasting code from local sources, Stack Overflow, GitHub, or an LLM—while kinda knowing what’s going on. 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. Given that distribution, I’d guess that well over 50% of Makefiles are just random chunks of copied and pasted code that kinda work. If they’re lifted from something that already works, job done—next ticket. I’m not blaming the tools themselves. Makefiles are well-known and not too verbose for smaller projects. They can be a bad choice for a 10,000-file monster—though I’ve seen some cleanly written Makefiles even for huge projects. Personally, it wouldn’t be my first choice. That said, I like Makefiles and have been using them on and off for at least 30 years.
  • f1shy 2y ago
    I would just change the percentages, but is about as true as it gets.
    • mianos 2y ago
      I’d be curious to hear your ratio. It really varies. In some small teams with talented people, there are hardly any “fake” developers. But in larger companies, they can make up a huge chunk. Where I am now, it’s easily over 50%, and most of the real developers have already left. PS: The fakes aren’t always juniors. Sometimes you have junior folks who are actually really good—they just haven’t had time yet to discover what they don’t know. It’s often absolutely clear that certain juniors will be very good just from a small contribution.
      • f1shy 2y ago
        My personal experience: - 5% geniuses. This are people who are passionate about what they do, they are always up to date. Typically humble, not loud people. - 15% good, can do it properly. Not passionate, but at least have a strong sense of responsibility. Want to do “the right thing” or do it right. Sometimes average intelligence, but really committed. - 80% I would not hire. People who talk a lot, and know very little. Probably do the work just because they need the money. That applies for doctors, contractors, developers, taxi drivers, just about anything and everything. Those felt percentages had been consistent across 5 countries, 3 continents and 1/2 a century of life PS: results are corrected for seniority. Even in the apprentice level I could tell who was in each category.
• bluocms 2y ago
  This only happens because people treat build code at a lower standard than app code. IMO you should treat all code with the same rigour. From build scripts to app code to test code. Why write hacks in build tools when you wouldn’t do in your app code. We build tool code with the same quality as the app code. That’s why most tooling we use are written in typescript: type safety, code reuse…
  • ido 2y ago
    I would argue the main reason is that Make is just bad. There are easier to use alternatives such as scons or rake that don't have this effect applied to them.
• nayuki 2y ago
  I see this effect in Java Maven pom.xml files. It's hard to get a straightforward answer on why each build step is needed, what each attribute means, what parts are optional or mandatory, etc. There seems to be a culture of copying these XML files and tweaking a few things without truly understanding what the whole file means. I briefly looked at Ant and Gradle, and their ecosystems don't look any better. The build configuration files seem to have too much unexplainable magic in them.
  • fiddlerwoaroof 2y ago
    Imo, the only solution is to avoid boilerplate generators and the parent poms projects like spring boot use for things like pom files: you can look at the boilerplate to get ideas for what might be necessary, but, if you’re starting a project, write the pom yourself. It’s a pain the first couple times, but it gets easier to know what you need.
  • rockwotj 2y ago
    Honestly for Java I really like Bazel. You should give it a shot. I have a project with a self contained jvm and jars from maven central. Its more explicit than the other options but way less magical IMO.
  • mongol 2y ago
    Java would really benefit from a fresh take on the build story. Maven is definitely a tool that suffers from this phenomenon.
  • imoverclocked 2y ago
    > I briefly looked at …Gradle… The build configuration files seem to have too much unexplainable magic in them. This is largely due to the use of groovy. When the Kotlin DSL is used instead, it can usually be introspected by (eg) IntelliJ. Otherwise, it’s pretty opaque.
    • brabel 2y ago
      Bullshit. Groovy can be introspected just as well as Kotlin. And the magic in kts files is still there: configure<SourceSetContainer> { named("main") { java.srcDir("src/core/java") } } Unless you know this, there's zero way you will come up with this by typing `configure` and using just auto-completion. Might as well use Groovy and a String for the name of the thing you're configuring. Good tooling would be able to auto-complete from there whether it's Groovy or Kotlin (or Java etc).
• smitty1e 2y ago
  What is the counter-example? We recycle known good stuff to avoid getting bogged down and introducing fresh flaws. The admonition to know what we're doing and act deliberately applies to so much in life, but flies in the face of Milton Friedman's point in "I, Pencil" => https://youtu.be/67tHtpac5ws?si=yhheE1Y5ELfjWXs- https://youtu.be/67tHtpac5ws?si=yhheE1Y5ELfjWXs-
• deleted 2y ago
  [deleted]
• mongol 2y ago
  Is not this a very generic phenomenon? I would argue it applies broadly. For example budgeting, you usually start from last year's budget and tweak that, rather than start from scratch. Or when you write an application letter, or a ServiceNow ticket, or whatever. Now I regret that I have brought in ServiceNow in the discussion, it kills the good mood....
  • Over2Chars 2y ago
    There's also "zero based budgeting" (ZBB) that starts from zero and says "justify everything".
    • KineticLensman 2y ago
      Which in my experience sometimes involves copying last years justifications
      • Over2Chars 2y ago
        It might! But as I understand it and I am not an accountant (IANAA?), for non-ZBB budgets last years budget is usually used as a starting point and increases are justified. "Here's why I need more money to do the same things as last year, plus more money if you want me to do anything extra". I'd be curious what our man Le Cost Cutter Elon Musk does for budgeting?
• parasti 2y ago
  I have made conscious effort in the past to never copy/paste the initial fleshing-out of a Makefile or a PHP class, or HTML boilerplate, or whatever. Like, for years I stuck to that. Then I stopped making that effort because there is no upside. Or rather, there is no downside to copy+paste+modify. It's faster and you save your brain power for things that actually matter.
  • tpoacher 2y ago
    There's a subtle difference between a nice template and a fully-working implementation that you then modify though. (e.g. in that they were designed with different goals in mind, so the former is likely to have stopped at the point where it was general enough, to save you time, but not too specific to create footguns). Bonus points if your template explicitly has fail patterns that prevent your code from silently failing.
• bitwize 2y ago
  A better name for this might be the JCL effect, as even experienced mainframe sysprogs copypasta the JCL it takes to build their COBOL programs from a known-good example and then mutatis the mutandis, rather than attempt to build a mental model of how JCL works from the impenetrable documentation and write JCL de novo. It's no big deal to me to write a small Makefile from scratch. My editor (Emacs) even knows to always use tabs when I hit TAB in a Makefile, removing the confusion of whether I inserted tabs (correct) or spaces (horribly incorrect) on the lines with the commands to build a particular target.
• dgan 2y ago
  Okey but to me, copying - pasting working code (even with sone extra unused bits) really looks no more different than inheriting a library - provided base class, and then extending it to one's needs. That's literally the basis of all software. There is no need to invent "a Makefile effect/syndrome" Yes that's an indication that a code sharing mechanism is needed but not implemented. Copying pasting solves that. You don't expect people to rewrite http client for every project which interacts with APIs, so you?
  • worldsayshi 2y ago
    I think this is a good point. As somewhat of a tangent I have vaguely been thinking of the difference between copy pasting and explicitly extending for a bit. It seems that in many cases, adapting copy pasted code has some benefits over importing and adjusting some library code. https://ui.shadcn.com/ https://ui.shadcn.com/ is an example of going the copy paste direction. It seems to me this is preferable when tweaking the exact behaviour is more important than keeping up to date with upstream or adhering to an exact standard. If you customize the behaviour a lot the extra abstraction layer only gets in the way. This insight might be a bit mundane. But I remember myself bending over backwards a bit too much trying to reuse when copy pasting is fine.
  • heisenbit 2y ago
    Well, I expect people to understand http clients and if things don't work to be sufficiently knowledgeable to recognize when they have a performance problem and figure out why they have it. For that one needs language, library and networking skills which to a degree most developers have because they do it every day. At issue however are niche skills. We are dealing with the long tail of a distribution and heuristics which work most of the time might not - the author mentions e.g. security. The way I look at this is risk i.e. security, bus factor, disruptions due to software moving from state "works and is not understood" to "broken and is not understood" and last but not least ability to predict behavior of this niche technology when it is going to be pushed into an larger project.
• yuppiepuppie 2y ago
  This is “Copy-Pasta Driven Development” [0] and it’s not even related to makefiles. It’s related to the entire industry copying code from here to there without even knowing what they are copying. TBH I think copilot has made this even worse, as we are blindly accepting chucks of code into our code bases. [0] https://andrew.grahamyooll.com/blog/copy-pasta-driven-development/ https://andrew.grahamyooll.com/blog/copy-pasta-driven-develo...
  • markfsharp 2y ago
    Could not agree more!
  • pdimitar 2y ago
    Blame the business people. I tried becoming an expert in `make` probably at least 7 times in a row, was never given time to work with it daily until I fully memorized it. At one point I simply gave up; you can never build the muscle memory and it becomes a cryptic arcane knowledge you have to relearn from scratch every time you need it. So I moved to simpler tools. The loss of deep work is not the good programmers' fault. It's the fault of the business people.
    • skydhash 2y ago
      I wouldn't say so. Make is very simple and you can grasp the basis within an hour or so, if you're familiar with shell scripting (as it's basically a superset of shell scripts, with the dependency graph on top). Then all you have to do is just in time learning which is mostly searching for a simpler pattern that what you're currently doing.
      • pdimitar 2y ago
        Hm, I'm not sure that's the case. Some of make's weirdness comes from bash-isms, not shell scripting in particular.
• g7r 2y ago
  We use Cargo Cult to refer to this phenomenon: https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming
• torstenvl 2y ago
  Copy+tweak happens IRL all the time. There's no reason everyone who bakes should have to reinvent biscuits from scratch. There's no reason chip manufacturers should have to reinvent N-type P-type sandwiches from scratch. The existence of adaptations of previous success does not suggest that baking, or physics, or Make, is overly complicated.
• Taniwha 2y ago
  I think this is completely normal for tools that you program seldomly. I write makefiles a couple of times a year, I've been using make for more than 40 years now, I use it every day, but I seldomly program it, and when I want something more than simple dependancies I often clone something that already works.
• agnishom 2y ago
  What is a counterexample? I cannot think of a single tool which is complex enough but does not show the makefile effect
• teddyh 2y ago
  “Just modify someone else’s Borgmon code and you’re good to go.” — Broccoli Man <https://www.youtube.com/watch?v=3t6L-FlfeaI https://www.youtube.com/watch?v=3t6L-FlfeaI>
• dvh 2y ago
  Most of my simple C projects have make.sh instead that has something like: clear gcc some options -o foo && ./foo
  • chikere232 2y ago
    You might benefit from make, as you wouldn't need a full rebuild every time, or have to spell out every step.
    • bigpingo 2y ago
      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.
• tpoacher 2y ago
  > However, at the point of design, this suggests a tool design (or tool application) that is flawed: the tool (or system) is too complicated (or annoying) to use from scratch. As someone who teaches and sees college-level students ask chatgpt what's 1 + 1, I disagree that it has anything to do with complexity or annoyance. Humans be humans; that's mostly it.
• vandahm 2y ago
  Honestly, my .zshrc file started out as a .kshrc file that was passed down to me by an older developer about 20 years ago, when I was still in university. I've added and removed a lot of things over the years, but there are still a few parts of it that I don't totally understand, simply because they work and I've never had a reason to think about them. The guy I got it from, in turn, got his from someone else. In the old days, I had a .fvwm2rc config file that I got from my boss in the university computing center. I had no idea how it worked! And neither did he -- he got it from a professor when he was in university.
• choeger 2y ago
  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.
  • klysm 2y ago
    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
    • mdaniel 2y ago
      > 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
• shusaku 2y ago
  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.
  • pantalaimon 2y ago
    it always feels like those are from an era where teletypes would print out the computer output on paper and brevity was key to save ink and paper.
  • kragen 2y ago
    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 I biffed it in a way that makes it nonfunctional, it will be obvious how to correct the problem. I mean, not that you can't do better than that (I'm pretty sure anyone experienced can see some problems!), or that there aren't tricky and annoying tradeoffs, but it just doesn't seem like a big activation barrier the way people sometimes make it out to be? Maybe those people just need to spend an afternoon once in their life working through a basic make tutorial? Maybe not the first time they work on a project using make, but, maybe, after the fifth or sixth project when they realize that this somewhat primitive inference engine is going to be something they interact with daily for years? At some point you're getting into "lead a horse to water" or "teach a man to fish" territory. There's a limit to how much you can empower someone who's sabotaging themself. There's a slightly less minimal example in https://www.gnu.org/software/make/manual/html_node/Simple-Makefile.html https://www.gnu.org/software/make/manual/html_node/Simple-Ma... with a full explanation. You can read it in a few minutes, but of course you have to experiment to actually learn it. The whole GNU Make 4.4.1 manual in PDF form is only 229 pages, so you can read it after dinner one night, or on your commute on the train over the course of a few days. And then you'll know the complete rules of the game.
    • 2y ago
• elcapitan 2y ago
  I guess this is an effect of declarative programming and layered abstractions. The declarative syntax and abstraction are an answer to code being repetitive and long and hard to follow, but this then creates its own issues by making it harder to reason (especially for beginners or occasional users) about what is actually going on. The price for learning how to get it right just becomes much higher with every layer of abstraction inbetween, because you always have to learn what's going on underneath the "cushions" anyway. For me typical examples are Terraform configurations with their abstracted configuration syntax, which just mimicks some other configuration (e.g. AWS) and executes it in an environment where I don't necessarily have access to. Of course I'm not going to run endless experiments by reading documentation, assembling my own config and running it in painful slow CI pipelines until it works. I'll rather copy it from another project where it works and then go back to work on things that are actually relevant and specific for the business.
• janalsncm 2y ago
  > Does it need syntax of its own? As a corollary: can it reuse familiar syntax or idioms from other tools/CLIs? I’m with the author here 100%. Stop inventing new syntaxes and formats for things that don’t need it. It’s not clever, it’s a PITA when it doesn’t work as expected at 3:30 on a Friday.
• Havoc 2y ago
  To me it seems fine that a tool that is both complexity and versatile needs a config file that is beyond memorization. So I think this line of reasoning has limitations. I could see it with say CLI tools though. Like if I need to reference my notes for a CLI command then that may well indicate a failure in tool design. >repeatedly copy a known-good solution and accrete changes over time. Alternative phrasing would be that it evolves. Arguably there is a positive trajectory there
• m463 2y ago
  There's another similar concept that sort of goes along with this. Sometimes it's better to duplicate code rather than make a special routine to do it. Sometimes it's not only easier to copy/paste, but it is better than adding a level of abstraction
• camgunz 2y ago
  This is pretty thought provoking. I think the issue is "80% of the use of this complicated tool is for very simple ends". From there you get a lot of "I can't be bothered to learn git/make/sed/helm/jenkins, all I'm doing is X 15 minutes a year". My guess is SWEs hate ceilings, so we don't want to use tools that have them, even though they'd be far more fit for purpose. We also don't want to build tools with ceilings: why limit your potential userbase/market?
• PaulKeeble 2y ago
  I end up doing the copy paste thing quite a lot with build tools, it was very common in Ant, Maven and then in Scala build tool. When your projects all have the same fundamental top level layout and you are doing the same actions over and over you solve the problem once then you copy and paste it and remove the bits that don't apply. These types of tools there isn't much you do differently they don't give you much in the way of abstractions its just a list of actions which are very similar between projects. Since you typically with them are working in declarations rather than the usual programming primitives it often fundamentally falls down to "does my project need this build feature or not?".
• davidguetta 2y ago
  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 Makefile that does this" or even "please simplify the Makefile that i copy/pasted/modified", my experience is that they do that very well actually.
  • uludag 2y ago
    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.
    • cindycindy 2y ago
      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 https://news.ycombinator.com/item?id=42646989
    • davidguetta 2y ago
      But LLMs is literally a "person in the room" that actually knows how it works. The simplification and explanation abilities of chatGPT are off the charts in precisely these cases. I honestly don't understand why I'm being downvoted. You wanted a simpler make file before ? go spend 2 days learning the make syntax You want a simpler make file now ? just ask for it as long as as the explanation with it of all the concepts to ChatGPT and you'll get it
• earnestinger 2y ago
  > 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 steer you clear of common pitfalls of project structuring and building and publishing. One example for illustration: Out of source builds is rather good idea, but not imposed by make. So makefile is not enough, one needs all the life-lessons of using make, so inherited makefiles are better than written from scratch.
  • o11c 2y ago
    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.
    • earnestinger 2y ago
      One more shower thought. Those inherited makefiles are a solution in a search for a standard.
• jcarrano 2y ago
  I wouldn't say this is necessarily a bad thing. I wrote my first version of a Makefile with automatic dependencies and out-of-tree builds 10+ years ago and I have been copying and improving it since. I do try to remove unneeded stuff when possible. The advantage is that one can go in and modify any aspect of build process easily, provided one takes care to remove cruft so that the Makefile does not become huge. This is very important for embedded projects. For me, the advantages have surpassed the drawbacks (which I admit are quite a few). You could, in theory, abstract much of this common functionality away in a library (whether for Make or any other software), however properly encapsulating the functionality is additional work, and Make does not have great built-in support for modularization. In this sense I would not say Make is overly complex but rather the opposite, too simple. Imagine how it would be if in C global variables were visible across translation units. So, in a way, the "Makefile effect" is in part due to the nature of the problem being solved and part due to limitations in Make.
  • rini17 2y ago
    Can you imagine the makefile was made by someone else and you are now suddenly confronted with the result of 10 years of tuning.
    • jcarrano 2y ago
      I am that someone else because I seldom edit the makefiles and I forget things. That's why I try to trim unused targets and recipes and I try to keep it documented. In the end it is no different from any code that's suffered from 10 years of tuning and it can get ugly. Maybe Make is even somewhat worse in this respect, but then again it does not need to be changed often.
    • imtringued 2y ago
      I would let the expert do his job and I do mine.
• keepamovin 2y ago
  In other news I like the coherence of your online digital identity and websites. Reminds me of the early internet. Auras of class, cred, erudition, intelligence, mystery, imagination. Thank you.
• teeray 2y ago
  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 confused response, because that is what was there. There is an implicit assumption that the code written espouses best-practices, but that is far from the truth.
  • neonsunset 2y ago
    I can imagine these developers being frustrated with highly verbose and often unsound semantics of Go.
  • rednafi 2y ago
    IDK I feel like Go suffers from this a lot. I have seen a lot of Gava, Guby, and G# over the last few years. It happens in Python a lot as well. Some people just love to write Java in Python and the new type hints make it even easier.
  • nwallin 2y ago
    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<double>::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.
• Scubabear68 2y ago
  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 of course is the islanders did not understand the science behind planes, Wallis talkies, guns, etc. Likewise, cargo cult devs see what is possible, but do not understand first principles, so they mimic what they see their high priests of technology doing, hoping they can copy their success. Hence the practice of copying, pasting, trying, fiddling, googling, tugging, pulling and tweaking hoping that this time it will be just right enough to kind of work. Badly, and only with certain data on a Tuesday evening.
  • qwery 2y ago
    The article does kind of mention this in footnote '1', for what it's worth: > The Makefile effect resembles other phenomena, like cargo culting, normalization of deviance, “write-only language,” &c. I’ll argue in this post that it’s a little different from each of these, insofar as it’s not inherently ineffective or bad and concerns the outcome of specific designs.
  • lolinder 2y ago
    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 motions or rituals. What OP is describing isn't like this because the thing being copied—the code—actually is effectual in its own right. You can test it and decide whether it works or not. The distinction matters because the symptoms of what OP calls the Makefile effect are different than the symptoms of cargo culting, so treating them as the same thing will make diagnosis harder. With cargo culting you're wasting time doing things that actually don't work out of superstition. With the Makefile effect things will work, provably so, but the code will become gradually harder and harder to maintain as vestigial bits get copied.
• gavindean90 2y ago
  No one tell them about Cobal
• svilen_dobrev 2y ago
  Apart of not knowing / unable to start from scratch, this is about frequent, and infrequent use. The latter also means not-that-important-in-overall-landscape, and brings forgetting and perceiving it as less "ROI", so one (hopefuly) finds and copy-pastes that-last-working thing into.. whatever Frankenstein. https://utcc.utoronto.ca/~cks/space/blog/programming/FrequentVsInfrequentDevs https://utcc.utoronto.ca/~cks/space/blog/programming/Frequen...
• fargle 2y ago
  calling this "Makefile" effect is a terrible disservice. one could as easily call it "PHP" effect, "YAML" effect, etc. pick whichever language you'd personally like to denigrate. there is nothing that makes makefiles inherently more or less susceptible to this. if it's more common, it's because people don't want to take the time doing more solid engineering and clean design for something like a ci/cd config or a makefile, being viewed as ancillary or less important. and so they often don't want to learn the language, so monkey-see-monkey-do. as sibling comments state, this is better called cargo cult or maybe copy-pasta. and i've seen it with any language c, c++, python, scripts, config files, anything. i even see it in chat gpt answers because it's regurgitating someone else copy pasta. if it's a problem, it's a problem of discipline.
  • rednafi 2y ago
    But it sure makes it more memorable. I would’ve called it GitHub Actions effect.
  • cassepipe 2y ago
    The reason why it seems to apply to makefiles in particular is because most people think life is too short to bother learning and understanding makefiles so it seems to happen there more than anywhere else. Also no matter how complicated and subtle you think your makefile is, true experts will tell you it's wrong and you instead copy their apparently over-engineered, hard to understand makefile
    • fargle 2y ago
      > Also no matter how complicated and subtle you think your [thing] is, true experts will tell you it's wrong and you instead copy their apparently over-engineered, hard to understand [thing] not unique at all to makefiles, probably not even in the top ten [things] that "true" experts like to "help" with
  • earnestinger 2y ago
    I think article addresses > if it's a problem, it's a problem of discipline. With this > Also note: the title is “be aware,” not “beware.” The Makefile effect is not inherently bad!
• getnormality 2y ago
  Another factor is frequency of use. I use LaTeX to do big write-ups on the order of once per year or less. LaTeX at the level I use it is not a hard tool, but I generally start a new document by copy-pasting a previous document because there is a lot of detail about how to use it that I'm never going to remember given that I only use it for a few weeks once a year.
  • Linux-Fan 2y ago
    I usually try to avoid the "makefile effect" by learning the technolgoy I use reasonably frequently (like e.g. Makefiles, Shell Scripts, ...). However, despite the fact that I used to use LaTeX very much, I always copy-pasted from a template. It is even worse with beamer presentations and TikZ pictures where I would copy-paste from a previous presentation or picture rather than a template. For TikZ I am pretty sure that the tool is inherently complex and I just haven't spent enough time to learn it properly. For LaTeX I have certainly spent enough time on learning it so I wonder whether it might be something different. In my opinion it could very well be a matter of “(in)sane defaults”. Good tools should come with good defaults. However, LaTeX is not a good tool wrt. this metric, because basically all my documents start something like ~~~ \documentclass[paper=a4, DIV9, 12pt, abstracton, headings=normal, captions=tableheading]{scrartcl} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage[english,german,ngerman]{babel} \usepackage[english,german]{fancyref} % ... \usepackage{microtype} \usepackage{hyperref} ~~~ Most of this is to get some basic non-ASCII support that is needed for my native tongue or enable some sane defaults (A4 paper, microtype...) which in a modern tool like e.g. pandoc/markdown may not be needed... Hence the purpose of copy-pasing the stuff around is often to get good defaults which a better tool might give you right out of the box (then without copy/paste).
    • kccqzy 2y ago
      Copy-pasting itself is not bad per se. What's bad is copy-pasting without understanding the why and how. For LaTeX I also copy-paste a whole lot from older files, but I don't feel bad because (a) I wrote these files before, (b) I know exactly what each line is doing, (c) I understand why each line is needed in the new doc. I wrote a relatively large amount of TikZ code earlier in my life (basically used it as a substitute for Illustrator) and for this library in particular, I think it just has so much syntax to remember that I cannot keep it all in my brain for ever. So I gladly copy from my old TikZ code.
• rednafi 2y ago
  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.
  • linuxftw 2y ago
    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-<target-script> that calls /app/<target-script>.sh inside the container." I don't have to care about Makefile syntax anymore for the most part.
    • rednafi 2y ago
      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.
  • stefr- 2y ago
    > 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. This resonates with me, I was in exactly the same position when I needed to do something with `kubectl` JSON output - just ask ChatGPT because I couldn't be bothered to learn the unintuitive syntax. Interestingly I _can_ blame the tool, because I started using Nushell[1] which has built-in JSON manipulation that provides a MUCH simpler syntax, and I have learnt this properly because it was that easy. 1: https://www.nushell.sh/ https://www.nushell.sh/
    • rednafi 2y ago
      Nushell is awesome. Too bad the incompatibilities are still a bit too much for me to use it as a daily driver. It’s easy to blame the tool, but sometimes the problem space is inherently complex. With limited time, building the right abstraction is an immensely difficult job. LLMs fixed this issue for me, and I’ve stopped complaining about unintuitive but ubiquitous tools.
• dave333 2y ago
  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.
  • sgarland 2y ago
    Sure, but IME even when the tool in question is incredibly well-documented (like Django, or some other popular library), and has plenty of examples, most still don’t read the docs. I don’t know how to deal with that mentality. I don’t mind showing someone how I came to an answer, but I also expect them to remember that for the next time, and do some searching of their own.
• dare944 2y ago
  > However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application. The author's overall point is fine (specifically, that one should consider developer cut-and-paste behavior as an indicator of unnecessary complexity in a tool). However, when discussing the designer's perspective, I think the author should have taken a broader view of complexity. Much of the complexity in Makefiles stems from their generality; essentially, the set of problems to which a Makefile can be a solution. Substantively reducing this complexity necessarily means eliminating some of those use cases. In the case of make, this is clearly possible. Make as a Unix tool has been around for a looong time, and one can look at the early versions for an idea of how simple it could be. But the rub is, simplifying make doesn't necessarily reduce complexity. Once armed with a simpler, but more limited make, developers are now tasked not only with knowing the easier Makefile syntax, but also knowing when make isn't an appropriate solution, and when and how to use whatever tool exists to fill the gap. Compounding this is the fact documentation and shared knowledge regarding which tool is appropriate for which problem is much harder to come by than documentation for the tool itself. This can easily lead to the tool choice equivalent of developer cut-and-paste behavior: "so-and-so uses build tool X so I must use it too", "if your doing (general description of problem) the only build tool you ever need is Y", "I used Z before, so I'm just going to make it work again". Essentially you can think of make as one "verb" in a sprawling and uncoordinated domain-specific language that targets building things. Developers need some level of proficiency across this language to succeed at their work. But trading complexity that must be mastered in one tool for complexity that must be mastered across tools can very easily increase overall complexity and promote its own kind of "Makefile Effect", just at a different level. EDIT: Some might prefer the term "Cargo Culting" rather than "Makefile Effect" here. I suggest they are the same behavior just in different contexts.
• matsemann 2y ago
  Why do some tools have this problem, and others not? I think it's convention over configuration. Makefile can do anything, so every project is different and needs different configurations, and everything must be configured. Which means that when I use a tool like that, it's sooo many decisions to make, that I just copy something that I know works. If instead it was some sane defaults, it would be pretty apparent where it deviates. And instead of thinking of hundred things and which to choose, I either don't think about them, or think "do I have a reason to configure this instead of using defaults?"
• layer8 2y ago
  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.
• knallfrosch 2y ago
  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.
  • frankzinger 2y ago
    Any long-lived project's build will have to be updated/improved at various times throughout its lifetime so there needs to be somebody around who truly understands the build.
• myhf 2y ago
  "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." – John Gall (1975) Systemantics: How Systems Really Work and How They Fail https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  • jfengel 2y ago
    It's why I'm always very skeptical of new languages and frameworks. They often look great on a PowerPoint slide, but it's not clear how they'll look on something complex and long-lasting. They usually pick up warts added for some special case, and that's a sign that there will be infinitely many more. There's a fine line between "applying experience" and "designing a whole new system around one pet peeve". But it's a crucial distinction.
    • wellbehaved 2y ago
      With that attitude how would the presently accepted languages/frameworks have come about?
      • oblio 2y ago
        Probably slower and with more respect for existing tech. But hey, now we have npm, so who cares anymore? :-)
        • mrcsd 2y ago
          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.
          • johnnyanmac 2y ago
            I can't agree with that take. Criticism is a part of progress. You can be a critic but still be respectful. Disrespect is simply to belittle and look down upon. I don't see many situations where such an attitude leads to progress.
• Learner100 2y ago
  A design philosophy called "Progressive Disclosure" tries to tackle this problem, where a tool is supposed to present a minimal set of functionality initially to allow a user to be productive without being an expert and progressively "reveal" more complex features as the user becomes more familiar with the tool and attempts to do more complex things. I've heard the programming language Swift followed this philosophy during development, though I've never written any Swift code to know how well it worked out. https://en.wikipedia.org/wiki/Progressive_disclosure https://en.wikipedia.org/wiki/Progressive_disclosure
• bluedino 2y ago
  This happens with Slurm/PBS job submission files. Always end up asking the user "where/who did you get this from?"
  • earnestinger 2y ago
    What is slurm?
    • bluedino 2y ago
      https://hpc-wiki.info/hpc/SLURM https://hpc-wiki.info/hpc/SLURM
• silasdavis 2y ago
  Someone remind me, is it $@ or $< ?
  • pwdisswordfishz 2y ago
    For what?
  • spc476 2y ago
    In a given rule: foo.o : foo.c $(CC) $(CFLAGS) -o $@ $< The "$@" is the output (or target, think of @ as a bullseye on a target), and the "$<" is the input (think redirection). The only other commonly used variable is "$^": foo : foo.o util.o other.o $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) In this case, "$^" means "all inputs".
• pwdisswordfishz 2y ago
  Ironically enough, I tend to write my Makefiles from scratch nearly every time, which means I have little reason to consider this term fitting.
• gsbcbdjfncnjd 2y ago
  Counterpoint: make is good actually, you should learn it (like all such tools).
• solatic 2y ago
  > 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.
  • semi-extrinsic 2y ago
    > 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.
    • upbeat_general 2y ago
      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.
• IgorPartola 2y ago
  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.
  • Quekid5 2y ago
    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.)
    • IgorPartola 2y ago
      That’s why I usually write them from scratch and don’t let them get over 100 lines long at most. Usually they are around 30 with white space. make clean makes lots of sense but is not even strictly necessary. In the world where all it does is find all the *.o files and deletes them it’s not a bad thing at all.
    • mauvehaus 2y ago
      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.
• PaulHoule 2y ago
  There are many angles. Part of the low-code/no-code story is that conventional programming requires programmers to not just decide what has to be done but in what order to put those things. (This is connected with parallelism because if tasks are done in a particular order you can't do more than one at a time.) An Excel spreadsheet is different from a FORTRAN program, for instance, because you can write a bunch of formulas and Excel updates the results automatically without you sequencing things. https://en.wikipedia.org/wiki/Topological_sorting https://en.wikipedia.org/wiki/Topological_sorting is an easy approach to finding a valid order to do tasks in. It's used frequently in build systems but rarely in other software so it contributes to build systems seeming to be from another planet --- I work in Java a lot and I used to hate Maven, because, if you look at Maven as "an XML vocabulary" you're going to frequently find "you can't get from here" and looking for answers in Stack Overflow is going to dig you in deeper. The right way to think about Maven is that, like (part of) Spring, it is a system for writing XML files that configure a group of Java objects. Seen that way, writing a Maven plugin should be a second resort; the moment you're scratching your head wondering if it's possible to do something, you should (1) make sure you can't "go with the flow" and follow conventions, then (2) write a Maven plugin. The thing is, a Maven plugin is just an ordinary Maven class. You're a Java programmer, you know how to do things in Java. All the skills you use everyday apply, you're no longer in a weird, mysterious and limited environment. That's part of the "makefile program"; you probably build your code (edit files in Java, C, whatever) 1000s of times for every time you change something about your build system. On a team you can be very productive if you know the main language but have no idea about how the build works (if the build the works.) When you try this though you often run into political problems. In most places, for instance, only a few people on the team have the authority to create new maven projects (a plug-in is a class defined it's own project.) Maybe that makes sense because you don't want them breeding like rabbits, but a lot generally most systems are badly partitioned as it is, and I think many programmers wouldn't want to have the fight it would take to create a new project. People are accustomed to builds being SNAFU and FUBAR. When I first saw Maven I was baffled that, as a remote working on a system that had about 20 programmers and about 20 projects I couldn't build the system successfully at all. The build worked maybe 70% of the time at the office and people didn't seem to worry about it. I could live with that because they were building large complex systems that they were always throwing away and I was building simpler spike prototypes that worked. I worked at a number of places where builds were unreliable in ways that seemed quantitative rather than qualitative, eventually I realized the problem was really simple, if you were using snapshot builds and a lot of people were working on a project and you didn't have any transaction control you would often get a set of snapshots that were not compatible with each other. Most teams don't take builds seriously enough. I've found it rare to meet an engineering manager who can answer the question "how long does the build take?" and fantasize of going to a job interview, asking that question, and if I don't get an answer, standing up and walking out. For many projects I've worked on I've built "meta-build systems" where the assumption is that have 12 maven projects and 4 npm projects or something like that (aren't most of us using mixed languages in the React age? why isn't this treated as a first-class problem), and such a system can be smart about what gets built and what gets doesn't, what is running out of snapshots and what can have a fixed version, etc. Merges in changes from develop automatically, and if seven steps are required that take a total of 15 minutes I ought to be able to think about something else entirely for 15 minutes and hear a "beep" when it's done. Trouble is we don't take builds seriously enough: it's a technical problem and it's a political problem and we often don't face the technical problems because of the political problems.
• __turbobrew__ 2y ago
  This happens to me all the time with bazel. It is too complicated and the documentation sucks so I just look for prior art and copy paste that. Sometimes I have to do something novel and it takes me several days of deep diving the bazel source code to figure out how to do something.
• DavidPiper 2y ago
  > 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.
• hedora 2y ago
  Make has to be one of the more unfairly maligned languages out there. Most “replacements” purport to solve problems make doesn’t have, and are strictly worse than make at what they do. Anyway, the GNU make manual is a good read for anyone that needs to edit a makefile or design a project build. So is “recursive make considered harmful”.
• ezekiel68 2y ago
  I do write makefiles de novo (including in corporate settings). But I start "backwards" with the "clean" and "distclean" targets, then get a single basic debug build target working. From there, I find it relatively easy to expand to larger and more complex operations. Brick by brick.
• Glyptodon 2y ago
  Common denominator is that people want a complex system to instead be something that can meet their simpler needs without being a time sink.
• jappgar 2y ago
  I dunno they're using copy-paste as if it's a bad thing. There's no virtue in writing something character by character. If anything these languages and systems are better for the Makefile effect. That you can't really do effective copy-pasting in imperative languages is a weakness.
  • stefr- 2y ago
    The author mentions that copy-pasting code by itself is not a bad thing. The problem with the phenomena they describe is that people copy-paste files around because they _don't understand it_, and end up with stuff that works, but is inefficient and hard to debug.
• simpaticoder 2y ago
  The tacit assumption of the OP is that it is better to do something else. That is, to start with some sort of first principles and create from scratch the artifacts that your project needs. It is telling that his example is a build artifact - these tend to change infrequently. The only way for one human mind to truly "dwell" in the space of project builds is to maintain many of them at once, as many as it takes to fill your days with nothing but build concerns. "Tools that enable this pattern are harder to use securely..." Harder than what? A totally custom build? One made from first principles? I would, in fact, argue the exact opposite. And in fact I would argue that copy-paste-modify serves practicioners very well, especially when it comes to on-boarding. If you disagree, do the gedankenexperiment where you imagine joining a team with a totally custom build versus one with a lightly edited common make file. Which experience would you prefer, all else being equal?
• Enginerrrd 2y ago
  This is how I feel about systemd unit files for things that I used to use crontab for. They aren't even particularly complicated. But editing cron files was self-explanatory. I leanred it once and I did not need to look it up ever. Whereas, systemd unit files, I still have to lookup every single time. There's something wrong with that. They are of course very much superior in many ways... but not all.
• 0xbadcafebee 2y ago
  So, it's the tool's fault that the user chose it, and it's the tool's fault the user never learned how it works? This is like taking a hike up a rocky hill because the trailhead had a smooth path, later tripping over a rock, and then blaming the rock. I'd redefine the Makefile (or YAML, Bash, etc) effect as: Tools that are easy enough that people try to use them without learning how they work first, and hard enough that people later blame the tool when they crash into their own ignorance.
• znpy 2y ago
  This is poor reasoning and poor argumentation. This particular line is wrong in my opinion: > the tool (or system) is too complicated (or annoying) to use from scratch Unless you're doing trivial things, any tool or system will require some setup (which people call "ceremony"). Tools and systems can be easy to use from scratch only if they are either super-specialized or they impose significant constraints on what you will be doing with that tool and how you will be doing it. Such tools are usually very tightly couple to a specific job/environment/task and are hard to keep around, keep updated and to evolve. Make and similar tools instead are generic and can be adapted. The fact that you can reuse the previous work done is actually a feature. You can dive as deep as you want or need. They're very widely used so it's not an issue to keep updated. They're so widespread you can find people already familiar with those tools. Learning such tools is a great investment because you can keep using them over and over across project and companies. Some of those tools are either timeless (gnu make) or have a very long life (more than a decade, which very long for this industry). Anecdotal example: I learned a bit of apache ant while in high school because my laptop at the time (a netbook with 1GB ram and an atom processor) could not run NetBeans decently, so I had to learn a bit of apache ant and resort to writing and maintaining my own build.xml file. Fast forward 14 years and I see a build.xml file in the $FAANG codebase I was working on. That learning did pay off beautifully many years later. The article is shortsighted, if anything it's promoting a shallow way of working. You are supposed to learn about the tools you use.
• Johndavid20224 2y ago
  [dead]
• isakellinor 2y ago
  [dead]