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

Be Aware of the Makefile Effect

blog.yossarian.net

Post reply on HN
Print view View original

171–180 of 347 posts

Re: Be Aware of the Makefile Effect

#171

Post by kragen »

remus wrote: post #166
kragen wrote: post #99

Earlier quoted context omitted.

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

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time. Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10…

I agree. And there's no infallible algorithm. I think there are some good heuristics, though:

- invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful

- invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the Lindy Effect

- invest more of your time in skills that are broadly applicable (algorithms, software design, Python, JavaScript) rather than narrowly applicable (PARI/GP, Interactive Brokers)

- invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff.

- be willing to try things that may not turn out to be useful, and give them up if they don't

- spend some time every day thinking about what you've been doing. Pull up a level and put it in perspective

Re: Be Aware of the Makefile Effect

#172

Post by dare944 »

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

Re: Be Aware of the Makefile Effect

#173

Post by kragen »

pdimitar wrote: post #115
kragen wrote: post #102

Earlier quoted context omitted.

Maybe switch to less frequently updated dependencies and rewrite the easy ones in-house?

Yes, and I should overrule half the business decisions of the company while I am at it. Oh, and I'll push back on "we need the next feature next week" and I'll calmly respond "we need to do excellent engineering practices in this company". And everybody will clap and will listen to me, and I will get promoted. ...Get real, dude. Your comments come across a bit tone-deaf. I am glad you are in a privileged position but…

I know a lot of people have terrible jobs at profoundly dysfunctional companies. I've had those too. That situation doesn't improve unless you, as they say, have the serenity to accept the things you cannot change, the courage to change the things you can, and the wisdom to know the difference.

Not everyone has a position where they have the autonomy to spend a lot of effort on paying down technical debt, but some people do, and almost every programmer has a little.

I think it's important to keep in view both your personal incentive system (which your boss may be lying to you about) and the interests of the company.

Re: Be Aware of the Makefile Effect

#174

Post by sgarland »

dave333 wrote: post #169

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.

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.

Re: Be Aware of the Makefile Effect

#175

Post by raverbashing »

cle wrote: post #144
Scubabear68 wrote: post #127

The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area. The issue…

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

Pretty much this

And of course every one of those tools has to have their own special language/syntax that makes sense nowhere else (think of all the tools beyond make, like autotools, etc)

I don't care about make. I don't care learning about make beyond what's needed for my job

Sure, it's a great tool, but I literally have 10 other things that deserve more of my attention than having my makefile work as needed

So yeah I'll copy/paste and be done with it

Re: Be Aware of the Makefile Effect

#176

Post by ttyprintk »

aragilar wrote: post #108
sandbach wrote: post #63

Earlier quoted context omitted.

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}

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

Definitely true for linting. Nothing unlike a linter solves the problems we want the linter to solve.

Re: Be Aware of the Makefile Effect

#177

Post by nrclark »

choeger wrote: post #77
Loic wrote: 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.

(not the parent)

Make is - at its core - a tool for expressing and running short shell-scripts ("recipes", in Make parlance) with optional dependency relationships between each other.

Why would I want to spread out my build logic across a bunch of shell scripts that I have to stitch together, when Make is a nicely integrated solution to this exact problem?

Re: Be Aware of the Makefile Effect

#178

Post by rini17 »

jcarrano wrote: post #120

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…

Can you imagine the makefile was made by someone else and you are now suddenly confronted with the result of 10 years of tuning.

Re: Be Aware of the Makefile Effect

#179

Post by matsemann »

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?"

Re: Be Aware of the Makefile Effect

#180

Post by teo_zero »

brabel wrote: post #52
teo_zero wrote: post #19

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

> The printf alone is the real payload, the rest conveys no information. What are you talking about? Every line is important. #include 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 ne…

Thank you, but this thread was not about writing good code, but rather how often one ends up acritically copying existing "legacy" parts without even attempting to understand it.

I probably used the wrong words: "conveys no information" was meant as "is less meaningful than the printf". Just like switching on the PC every morning is essential, but if you ask me what my job's about, I wouldn't mention it.

In the same vein, I'm convinced that the printf is the part that expresses the goal of the program. The rest, the #include, the main(), even with the optimizations that you suggested, is just boilerplate, the part that is usually copied and pasted, not because it's not useful and not because it's too difficult to get right, as the original article claims, but because it's boring.

Post reply on HN