I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested?
The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension language (in latest versions).
Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.
That is not the argument though. The argument is: After being unhappy with Makefile for years now
As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated.
Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want to be the one introducing taskenv, direnv and derenv to a project.
But it was; one of his arguments. Yes, he opens with the argument that he was unhappy with the Make for years, but he later clarifies why:
> I am still stuck with a tool that (according to Wikipedia) has been written 47 years ago.
You probably haven't read his article to the end? Those were his words I copy-pasted from the blog. So one of the reasons he is unhappy is because Make is 47 years old. For some reason, it stopped to be good enough 20 years ago, according to his opinion.
I can give him that we can always have a better tool, but it is a tautology. Unfortunately, his offered alternative is not better IMO.
Software build has essential complexity. Dealing with peculiarities in config syntax is a mere drop in the vast lake of unhappiness wept from having to deal with build at all. It's the tools that are salient, so folks may perceive that it's the tools at fault and must be reworked, but it isn't really: complexity in build tools is an emergent property of the domain, and any sufficiently developed reinvention will asymptotically correspond to makefiles.
“The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing list of countries f.e ‘[GB, IN, NO,…]’
It's a good example of how you can overengineer a relatively simple format.
The reason is that they specify a boolean value as either "true/false" or "yes/no".
The last alternative causes problems not only for the Norwegian country code (no), but also in cases where you need to specify the actual word "yes"
You could of course end up with the same problem if you need to specify the literal "true" and "false", but by overengineering the acceptable boolean values, they increase the potential problem areas.
Claiming more common words as keywords basically. It's just not well considered. true and false are ordinary words, and it would probably be better if sometime way back someone had come up with special keywords that didn't conflict with ordinary words, but for good or bad, at least by now it's practically universal in most languages that true & false are keywords and everyone knows it. Claiming yes and no as keywords also was just thoughtless and inconsiderate (ok that was redundant), doubly so when they don't even do a new job but simply double the consumed namespace to do the same job that was already done by true & false.
Eh, it's fine if they're keywords as long as not everything is a string. If `"NO"` and `NO` are distinct types, then they're not equal and there's no Norway problem. YAML treats strings, numbers, null, and booleans as all the same type (scalars). The problem isn't keywords clashing with common words, it's not having distinct types!
A Boolean represents a true/false value. Booleans are formatted as English words (“true”/“false”, “yes”/“no” or “on”/“off”) for readability and may be abbreviated as a single character “y”/“n” or “Y”/“N”.
To be fair, YAML 1.2 does not suffer from the "Norway Problem", but YAML is still a rather complex format.
I feel like the Makefile syntax has some pesky warts, like not breaking when there are spaces in filenames, requiring tabs[1], the ceremony around PHONY targets... If you take the legacy stuff out of make,
[1] Apparently it can be fixed with a complex .RECIPEPREFIX incantation which behaves differently in different versions of GNU make, and was conveniently added just one minor version after Apple has graciously decided to stop updating all their GNU software versions.
Redo, ninja and tup seems like trying to do that, with their own twists, but none of them really managed to nudge make out;
I use make for (among other things) transforming files; batch compression being the simplest example, so all one requires is a rule saying %.log.xz : %.log and all is well.
But if people have colons in filenames, for example for timestamps, all bets are off, and make chokes spectacularly.
And that really sucks in Windows because every absolute path contains a colon. Not that absolute paths are common in makefiles, but it's not something that should break on a major platform.
It's more that doing the 80% solution lets us spend time developing other things. And then we can have a bunch of other really cool stuff as long as the users are willing to work with it.
Which seems like a pretty reasonable trade-off for something that's free.
It's the user serving themselves by naming files in a way that makes them easy to handle everywhere. There is also sorting and completion to consider in commonly-traversed directories.
Is it conceivable to you that steps are possible, and getting rid of dropbox is a step in a direction ? That perfect is the enemy of good ? That you can't wait to find a perfectly pure plan before starting moving ?
Do we know that taskfile does any better than make on this front? It isn't mentioned in the article. Sounds like taskfile is runs on raw "command line string interpolation" just like good old make.
I thought Nix used as Guix Guile under the hoos, but looked up now, and they seem to use custom language, in which case is it even worse. I should have looked up that before the hand, my bad there, I appologize.
Op complained about that make requires a bunch of extra tools to get running, and suggests another bunch of extra tools, as well as of make DSL which is more or less shell on steroids, but suggests a mix of two different languages instead, and does not even seem to be aware he can use Guile Scheme to extend Make.
It’s proof tested yes. But it still falls over if you put in a space versus a tab, and the error message is cryptic and frustrating to beginners. Make is such a huge impediment to C adoption, long time users have no idea.
Even the fact makefiles have no extension is confusing to beginners. Everything about it screams outdated, idiosyncratic computing artifact and students pick up on that.
Gatekeeping the entry to learn something is never good.
There’s a big difference in developing trust to contribute to a project and developing knowledge to start with a new language.
And I’ve worked with tons and tons of very amazing developers who aren’t comfortable with Make or even git because their careers have been with Visual Studio and other VCS. Therefore I don’t think it’s an adequate judge of skill.
I'm pretty glad they gatekeep pilots and surgeons and all kinds of other occupations.
Reading a manual, or failing to, is not gatekeeping. I learned how to write a Makefile in a few minutes, for free, with no one telling me I wasn't allowed to.
There is no "gatekeeping" argument here, just whingy babies that no one should waste 10 seconds caring about.
So, the 'easy on ramp guided path' to being allowed to pilot a plane or practice medecine, is as easy or even in the same universe with writing a makefile? Do you hear yourself? Talk about invalid arguments holy shit!
The easy on ramp was it was totally free and permissionless to learn how to write a Makefile, or read a bunch of existing ones, or countless howtos, and that a basic makefile is basic and you don't need to figure out the arcane bits until you want to, and at no point ever do you need a license no matter how easy or guided the path.
You can be a poor 10 year old in a 3rd world country and write a Makefile. No gates kept.
It's a depressing outlook on life to see something as simple a useful as make as some kind of problem where the supposedly superior answer is something ridiculous like python.
The fact that anyone even for one second thinks these are reasonable thoughts is what is truly depressing.
Is anger and derision your default state of discourse? Both your responses so far have been just completely over the top in both regards.
But putting that aside, you don’t think Make has a ton of footguns for someone starting out?
Spaces vs tabs for different bits because of decades of legacy? Oh but most editors default to tabs as spaces and suddenly no matter what you do, following tutorials will still fail.
Or you try and mess around with an existing open source project to learn from it. You want to list the targets? Oh wait, there’s no standard way to examine the makefile without understanding Make first.
If people consider Make easy to learn, imho they haven’t really reflected on how much more streamlined the rest of the software engineering ecosystem is, and how it benefits everyone from new programmers to experienced devs. I’m not the one saying it should be Python, I’m just saying Make is not a good solution in this day and age, when so many other ecosystems have shown they can have better on-boarding experiences.
Anyway I won’t respond further. Feel free to rage reply as you want.
Would anyone allow people without a drivers license onto the streets in a car? Is that gatekeeping or learning the rules of how a societal form of cooperation is practiced?
Now whether learning how make works is the same as driving a car is left to the reader to decide. Either way make is also a societal form of cooperation with its rules and traditions.
Where does gatekeeping start and where does societal norms and cooperation begin?
Are people just going to ignore that I have a clear delineation in my comment about the difference of learning and contributing to a project, and instead throw unrelated strawman arguments at me? Driving and programming are different, and learning to program and contributing code to important codebases is different. The stakes are different, the entire paradigms are different.
The on ramp to learn to drive is easy relative to actually being trusted/licensed to drive. But do I need to understand how an engine works to learn to drive? No. Maybe I needed to learn how gear changes worked in the day of manual transmission, but today with EVs and CVTs, why should learning stick be a gate to pass? That’s the equivalence of make to C
Regardless, all these analogies fall down because the crux of the issue is that if there are better alternatives that prevent issues, it isn’t sensible to keep using the old one.
Take your driving analogy. Should we force people to disable proximity sensors? After all you can drive without them but they make driving safer and easier for everyone.
Make is much the same way. It gets the job done, that doesn’t mean it’s good at getting the job done when better alternatives exist.
Point taken but why is learning yaml easier then learning make? It seems that if its about the amount that needs to be learnt then we'll get nowhere.
Make is easy for certain folks, yaml for others. If a project has been using make for years, should they be forced to replace it since someone believes they are gatekeeping? What happens if said project rejects a pull request that replaces said makefile with task file requiring python and yaml?
I'm pragmatic and also say if it gets the job done OK, but must I replace make with task if someone suggests I'm gatekeeping just because I have a pragmatic point of view?
the point isn’t to replace existing use. To take your analogy of cars, we aren’t retrofitting cars with new tech.
But maybe it means that new projects use a more accessible build system. I’m not saying Task is the answer, I’m just saying Make is an issue for a lot of reasons like accessibility and portability to multiple toolchains and systems.
If you’re just coding for yourself, it’s not important. Nobody is saying you should change. But if you’re coding for an ecosystem, it’s always worth evaluating where changes can be made and then evaluating case by case if the pros outweigh the cons.
> Should we force people to disable proximity sensors? After all you can drive without them but they make driving safer and easier for everyone.
I think your analogy is quite bad here. You ain't giving people proximity sensors or parking cameras or automatic parking. You are exchanging a good, comfortable vehicle we all know how to drive for a new type of vehicle with clearly worse ergonomics and forcing everyone to re-learn how to drive.
Once part of designing cars is that we can sit down in any car and just drive it. Perhaps we need to look up some minor and less important details, but we are guaranteed some very basic operation: how the blinking lights work, how to operate gas, brakes, steering wheel and manual transmission. I do think that they have messed up with short/long lights and back gears. That should have also been the same on all cars. But the basics are the same.
Makefile uses shell scripts for the recipes and shell variables, which makes Make an extension to the shell. There are differences, of course, but basics are very, very simple to get to learn. I learned 30+ years ago by just looking at other makefile and basically copying the details for my projects. I am still not even a very advanced makefile writer, I still lookup what automatic variables do, which one do I want and which functions I can use when I need them.
Honestly, I’m closer to ditching C as the language for my systems course and moving to Rust entirely. It’s much easier than trying to rationalize the state of affairs through this gatekeeping in the name of safety lens.
I thought we all decided that norms and just imploring coders to hold the tools the right way isn’t scalable. I thought the industry had moved to safety through tooling, not safety through peer pressure and hoop jumping.
I mean, if we’re talking about cortical systems and safety, why is anyone using C at all?
Don't forget, banks still use cobol... Should be replaced... If only someone could!
Herein lies the issue for me: should existing projects switch because they are deemed to be gatekeeping when in fact either they are fine with their technology choices or they have not the resources or knowledge to change but they aren't gatekeeping. The external appearance is the same whichever reason might be the truth.
I don’t think anyone’s advocating for changing old projects just for the sake of accessibility, but if someone was able to contribute a change that increases accessibility while preserving functionality, then that’s fine.
It’s how a lot of major OSS projects have shifted to cmake from make or scons. Granted cmake isn’t a pinnacle of ease of use either but it’s much easier imho to reason about and integrate with various tooling like IDEs
> If people consider Make easy to learn, imho they haven’t really reflected on how much more streamlined the rest of the software engineering ecosystem is
This right here. It goes back to my other comment about how those who are proficient with Make don’t understand how esoteric and arcane it is to beginners.
The attitude of “well it should be hard, the shouldn’t even learn C if they can’t handle make” is explains why my students love Rust so much. Rust has a sane and standardized build system they prefer to use. Make is the Stone Age to them.
And don’t get me wrong, they learn Make. They learn how to use it proficiently and we get through it. But at the end of the class, they will throw Make away and use another language like Rust. They simply do not want to deal with it.
Problem is if you care about the future, someone has to help the whingy babies become competent adults. Not everyone is a polymath autodidact that can absorb everything about computers like the HN crowd. Some rockstars start as whingy babies. If you don’t help them at that crucial time, the stay whingy babies, or worse, go on to become project managers. You don’t want the whingy babies managing your project.
And yet there are actually whingy babies and, and no not all developers were once a whingy baby, in fact only the shit end of the bell curve ever were. Most people I even know at all never were, because it's not an automatic part of merely being new.
There is no value in catering to them, since that generally requires blunt rather than sharp tools, and everyone else requires sharp tools to get actual work done. They can play with their toys, but they are toys thoight up by people who care about the wrong things. Anyone else should ignore and disregard them and their ignorant ideas.
Make is probably not the final evolution of a build sysyem for eternity, merely the arguments given for python of all the ridiculous possibilities, have all been garbage so far.
Now if a proposition included some sort of canonical flavor of python (or whatever language) that can be counted on to:
- exist on any system, and "any system" does not mean "any linux intall from today forward"
- could at least be added to any system if not already, ie, plain c source that compiles even on obscure old systems, or built out of something else equally ubiquitous like shell or awk.
- single simple binary
- all features included (no libraries of plugins and modules)
- spec advances only slowly and thoughtufully and without breaking compatibility
Make already exists, meets all of these points, and provides the means to express complex jobs or simple jobs without any special built-in magic support for any one language or framework of the month, especially not at the expense of any others.
Although, even a mythical "canonical python subset" would be a strange thing to propose with it's meaninful whitespace, when one of the main complaints about make is the tabs.
> But it still falls over if you put in a space versus a tab
It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.
> Even the fact makefiles have no extension is confusing
How is that confusing, the entire filename (makefile) is "the extension" :-)
Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen <vector>, <algorithm>, <iostream> etc?
The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension language (in latest versions).
Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.