Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

111–120 of 347 posts

Re: Be Aware of the Makefile Effect

#111
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?".

Re: Be Aware of the Makefile Effect

#112
post #91

Earlier quoted context omitted.

We can’t really call the field engineering if this is the standard. A fundamental understanding of what one’s code actually makes the machine do is necessary to write quality code regardless of how high up the abstraction stack it is

Sure if you are doing embedded programming in C. How does one do this in web development though where there are hundreds of dependencies that get updated monthly and still add functionality and keep their job?

The current state of web development is unfortunately a perfect example of this quality crisis. The tangle of dependencies either directly causes or quickly multiplies the inefficiency and fragility we’ve all come to expect from the web. The solution is unrealistic because it involves design choices which are either not trendy enough or precluded by the platform

Re: Be Aware of the Makefile Effect

#113
post #101

Earlier quoted context omitted.

Steam engines predate the understanding of not just the crystalline structure of steel but even the basics of thermodynamics by quite a few decades.

Yes and they’re far less efficient and require far more maintenance than an equivalent electric or even diesel engine, where equivalent power is even possible

Why do you assume that the same doesn't apply to electric and diesel engines ?

Re: Be Aware of the Makefile Effect

#114
post #12

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.

I guess that there's a very important difference between copying something that you understand (or at least the details of which, like syntax, you can easily remember - here comments become important),

and copying something that not only you do not understand, but you were not the one that made it in the first place, and you never understood it !

Re: Be Aware of the Makefile Effect

#115
post #102
post #91

Earlier quoted context omitted.

Sure if you are doing embedded programming in C. How does one do this in web development though where there are hundreds of dependencies that get updated monthly and still add functionality and keep their job?

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 you seem to have fell for the filter bubble effect and are unaware to how most programmers out there have to work if they want to pay the bills.

Re: Be Aware of the Makefile Effect

#116

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

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.

Re: Be Aware of the Makefile Effect

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

Re: Be Aware of the Makefile Effect

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

Re: Be Aware of the Makefile Effect

#119
post #107
post #70

Earlier quoted context omitted.

I would just change the percentages, but is about as true as it gets.

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…

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.

Re: Be Aware of the Makefile Effect

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

Post reply on HN