Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

201–210 of 347 posts

Re: Be Aware of the Makefile Effect

#201
post #123

Earlier quoted context omitted.

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…

Yes, sometimes things are unfixably broken, and it's impossible to build anything good. For everything else, there's MasterCard.

Any golden MasterCards with $50M one-time limit you could offer for free? I can think of a few things to fix with those.

RE: unfixably broken, well, not necessarily in concept but de facto you are sadly correct. Most people resist even the provably good changes.

Re: Be Aware of the Makefile Effect

#202
post #178

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.

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.

Re: Be Aware of the Makefile Effect

#203

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.

I use it more often and also start with copy-paste header, that includes:

* all packages needed for my language (fontenc, babel, local typography package) * typical graphicx/fancyhdr/hyperref/geometry packages that are almost always needed * a set of useful symbol and name definitions for my field

If you are not writing math or pure text in English only LaTeX is batteries not included.

Re: Be Aware of the Makefile Effect

#204
"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

Re: Be Aware of the Makefile Effect

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

Re: Be Aware of the Makefile Effect

#206

Earlier quoted context omitted.

Auto-generated Makefiles that CMake and Autotools produce really leave a bad impression on how complex Makefiles need to be.

Good news, you can change the output then! And for as much as you might not like its generated Makefiles, I assert that $(cmake -G Ninja) is 100,000,000x more "wtf" than -G Makefiles I disagree about the autotools ones, I find them very sane although autotools itself can die in a rotting dumpster out back. And take m4 with it.

Yeah, m4 is powerful in its way, and has an extraordinary strength-to-weight ratio (check out the implementation in Software Tools in Pascal) but ultimately I think it turned out to be a mistake. Make, by contrast, turned out to be a good idea despite its flaws.

Re: Be Aware of the Makefile Effect

#207

Earlier quoted context omitted.

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

> only worked within a broader context that is now missing > because the thing being copied—the code—actually is effectual in its own right. I don't understand how the second disproves the former. In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal…

> a cargo cult works

But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

Re: Be Aware of the Makefile Effect

#208
post #204

"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

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.

Re: Be Aware of the Makefile Effect

#209
post #173

Earlier quoted context omitted.

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

The serenity in question boils down to "I'll never make enough money to live peacefully and being able to take a two years sabbatical so let's just accept I'll be on the hamster wheel for life and I can never do anything about it". No. I'll let my body wither and get spent before my spirit breaks. I refuse to just "accept" things. There's always something you can do. BTW is that not what HN usually preaches? "Change…

I can't recommend others follow my path. Some of the results have been pretty bad. Hopefully your path works out well. We all die in the end.

Re: Be Aware of the Makefile Effect

#210
post #207

Earlier quoted context omitted.

> only worked within a broader context that is now missing > because the thing being copied—the code—actually is effectual in its own right. I don't understand how the second disproves the former. In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal…

> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked.

Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a helpful one imo.

Post reply on HN