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?".
Be Aware of the Makefile Effect
111–120 of 347 posts
Re: Be Aware of the Makefile Effect
#112Earlier 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?
Re: Be Aware of the Makefile Effect
#113Earlier 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
Re: Be Aware of the Makefile Effect
#114I think LaTeX is the poster child of this. Nobody writes a LaTeX preamble from scratch, you always copy your previous document and tweak it.
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
#115Earlier 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?
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
#116This 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...
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
#117The 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
#118I 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
#119Earlier 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…
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
#120The 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.