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.
Be Aware of the Makefile Effect
51–60 of 347 posts
Re: Be Aware of the Makefile Effect
#52> 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
int main(int argc, char** argv)
int main(void)
printf("Hello\n");
return 0;
So, here is the actual minimalist Hello world:
#include
int main(void) {
puts("Hello world\n");
}Re: Be Aware of the Makefile Effect
#53I 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 c…
> 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.
Re: Be Aware of the Makefile Effect
#54Is 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....
There's also "zero based budgeting" (ZBB) that starts from zero and says "justify everything".
Re: Be Aware of the Makefile Effect
#55I 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.
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.
A much better solution would be to use Typst, but that still might not work in all situations.
Re: Be Aware of the Makefile Effect
#56I 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 c…
> 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.
Bullshit. Groovy can be introspected just as well as Kotlin. And the magic in kts files is still there:
configure {
named("main") {
java.srcDir("src/core/java")
}
}
Re: Be Aware of the Makefile Effect
#57Okey 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 d…
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/ 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.
Re: Be Aware of the Makefile Effect
#58I 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.
Re: Be Aware of the Makefile Effect
#59Is 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....
There's also "zero based budgeting" (ZBB) that starts from zero and says "justify everything".
Which in my experience sometimes involves copying last years justifications
Re: Be Aware of the Makefile Effect
#60Earlier quoted context omitted.
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…
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?
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.