Common denominator is that people want a complex system to instead be something that can meet their simpler needs without being a time sink.
Be Aware of the Makefile Effect
301–310 of 347 posts
Re: Be Aware of the Makefile Effect
#302I dunno they're using copy-paste as if it's a bad thing.
There's no virtue in writing something character by character.
If anything these languages and systems are better for the Makefile effect.
That you can't really do effective copy-pasting in imperative languages is a weakness.
Re: Be Aware of the Makefile Effect
#303The tacit assumption of the OP is that it is better to do something else. That is, to start with some sort of first principles and create from scratch the artifacts that your project needs. It is telling that his example is a build artifact - these tend to change infrequently. The only way for one human mind to truly "dwell" in the space of project builds is to maintain many of them at once, as many as it takes to fill your days with nothing but build concerns.
"Tools that enable this pattern are harder to use securely..." Harder than what? A totally custom build? One made from first principles? I would, in fact, argue the exact opposite. And in fact I would argue that copy-paste-modify serves practicioners very well, especially when it comes to on-boarding. If you disagree, do the gedankenexperiment where you imagine joining a team with a totally custom build versus one with a lightly edited common make file. Which experience would you prefer, all else being equal?
Re: Be Aware of the Makefile Effect
#304This is how I feel about systemd unit files for things that I used to use crontab for. They aren't even particularly complicated. But editing cron files was self-explanatory. I leanred it once and I did not need to look it up ever. Whereas, systemd unit files, I still have to lookup every single time. There's something wrong with that. They are of course very much superior in many ways... but not all.
Re: Be Aware of the Makefile Effect
#305So, it's the tool's fault that the user chose it, and it's the tool's fault the user never learned how it works?
This is like taking a hike up a rocky hill because the trailhead had a smooth path, later tripping over a rock, and then blaming the rock.
I'd redefine the Makefile (or YAML, Bash, etc) effect as:
Tools that are easy enough that people try to use them
without learning how they work first, and hard enough that
people later blame the tool when they crash into their
own ignorance.Re: Be Aware of the Makefile Effect
#306> Think about CI/CD setups, where users diagnose their copy-pasted CI/CD by doing print-style debugging over the network with a layer of intermediating VM orchestration. Ridiculous! I don't think the author understands the point of "CI/CD systems". And I don't really blame them, because workload orchestration systems have been abused and marketed to the point where we call them CI/CD systems instead. Sure, if you thi…
> If you think you can just run your CI/CD on a single server without networking or virtualization, I have some very large, parallelized testing suites to show you. Nowadays you can get a single server with 256 cores and several terabytes of memory. I would be interested to learn what kind of testing suites have actual needs beyond that. Without virtualization though is definitely no problem. The whole docker/k8s/wha…
And you can get desktop workstations with similarly high core counts and RAM. You're missing the point. Your strategy can either depend on whether or not you can afford to buy out larger and larger vertically scaled servers, or you can plan for horizontal scaling. Almost nobody is willing to sign off on the vertical scaling strategy because the sheer presence of a ceiling frightens executives.
And yes, in enterprise, two things are usually at play: you need to test a system where the architecture includes the combined architecture of multiple corporate acquisitions, more than one of which were Vertical Monsters, and more than one of which presumed horizontal scaling; and where deployment scripts must be run from behind a no-ingress-permitted firewall, which means having workload orchestration runners installed behind that firewall.
Re: Be Aware of the Makefile Effect
#307"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…
> "designing a whole new system around one pet peeve"
BAHHAHAH! So…you mean React. If I hear the word hook as if it alone can solve complexity in web dev one more time I’ll…eh, I’ll do nothing actually. But my point still stands. React solves asynchronous event driven behavior well, but that’s all. Everything else in React projects is, well, everything else.
Re: Be Aware of the Makefile Effect
#308Earlier 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.
> For everything else, there's MasterCard.
I'm pretty sure that the original meme was «In God we trust; for everything else, there’s American Express» (with or without cocaine).
Re: Be Aware of the Makefile Effect
#309Yeah I'm just not wasting my life (or professional time) learning Groovy, Maven, DotNET project files, DotNET 4.8, Gradle, Azure DevOps, Grafana, Prometheus, Docker, Docker compose, Kubernetes, Jenkins etc et all. I need those things once at project setup. I copy-paste and change a bit. Why copy-paste? It's a proven strategy with a high success rate despite little effort behind it. I also don't want to learn templati…
Any long-lived project's build will have to be updated/improved at various times throughout its lifetime so there needs to be somebody around who truly understands the build.
Re: Be Aware of the Makefile Effect
#310Earlier quoted context omitted.
> I mean, sure, there's no time today to learn make to complete your C++ ticket or whatever. But yesterday? Last month? Last job? That seems like a weird way to think about this. Of course there was no time in the past to learn this stuff, if you still haven't learned it by the present moment. And even if there were, trying to figure out whether there perhaps was some free time in the past is largely pointless, as op…
To be clear: I'm not suggesting a time machine, and I'm not listing any particular set of skills everyone must have. I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.
You don't seem to understand that make is not a core skill.
In an ideal world build tools would just work and people wouldn't have to think about them at all.