Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

211–220 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#211
post #128

Earlier quoted context omitted.

Having hurdles to jump over is perhaps a good thing? After all Torvalds built git to have a hierarchy of trust in the development of Linux. If someone can't understand how to use make perhaps they shouldn't be fiddling with C.

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.

How is it different to learn Make from any other building tool like Gradle, Scons, Cmake, you name it?

Actually, basic is very simple, since the syntax is pretty much like the shell, or I mean, it is more or less shell scripts on steroids.

Re: Taskfile: A Modern Alternative to Makefile

#212

Earlier quoted context omitted.

You can't run linux without python these days, and it's not hard to stick to packages available in the repositories.

It's very rare, most distros ship Python, and even mac does it. But: - Half of the devs in the world are on Windows. - Installing doit with pip is not trivial. Hence the "Relieving python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-p... And most people will never ever encounter this article, so they will hit a missing command, a missing package, a PATH error, a PYHONPATH erro…

Thankfully, every major distribution packages doit, so you don't need to touch pip at all

https://repology.org/project/doit/information

Re: Taskfile: A Modern Alternative to Makefile

#213
post #173

Earlier quoted context omitted.

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…

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

> 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.

Re: Taskfile: A Modern Alternative to Makefile

#214
post #184

Earlier quoted context omitted.

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

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…

Accessible is merely an opinion not a fact or an argument backed by a fact.

Make is the definition of portable for that job, so that was a weird argument to try to make.

I see a consistent pattern of unfounded argument from someone who has nothing more than "old=bad" or "new=progress"

Re: Taskfile: A Modern Alternative to Makefile

#215

Earlier quoted context omitted.

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.

Whingy babies, freshmen students… tomato tomato. 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…

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.

Re: Taskfile: A Modern Alternative to Makefile

#216

Earlier quoted context omitted.

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…

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…

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!

Re: Taskfile: A Modern Alternative to Makefile

#217
post #76

Earlier quoted context omitted.

Can you use spaces in filenames with GNU make yet? Seems like a 47yo vestige when spaces in filenames weren’t really a thing…

Or just don't use spaces in filenames. It just causes trouble for no benefit.

/Τĥιs ñåmè įß ą váĺîδ POSIX /paτĥ

Re: Taskfile: A Modern Alternative to Makefile

#218

Earlier quoted context omitted.

I didn't like the transition from SVN to Git. My biggest problem was the commit numbering. While SVN assigned consecutive numbers to commits, Git assigned hashes. I still think that most people working with VCS today would've been better off using SVN. Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Most people using Git today don't know how to go back in…

> Most companies use Git in a centralized way anyways -- they don't need the distributed feature of the system. Even if you have a single centralized remote, git being distributed lets you work offline, because you have a full copy of the repository, and you can commit locally. > Most people using Git today don't know how to go back in history and wouldn't be physically able to carry out this task if requested Google…

> Google exists and can help

Google isn't going to help if you were doing merges for a year, and then discovered you need to go back in history, and now you realize you should've been doing rebases instead. Google all you want -- it will be of no use, because your repository is a pile of garbage at this point, and it's not humanly possible to go back in time. Like I wrote in the post you replied to -- most programmers use Git where rsync would do.

> git being distributed lets you work offline

You could do that with SVN too. It was actually my other complaint about Git. Both SVN and Git use the word "commit", but those two mean different things. SVN "commit" is more like Git "push". Perhaps, you'd have to work harder in SVN having to reconcile the changes you haven't committed for a while, esp. because the tradition was for many developers to work on the same branch, but not impossible.

> If you have more than one person, how can a repository be write-only?

Do merges instead of rebases. When I say "write-only", I mean that the history of the repository is worthless -- it's written, but it's not actionable. This isn't apparent with smaller teams who have very few branches and work on a relatively small project. With larger teams merges in a repository create a ball-of-yarn history. I mean, you can read it, technically, but even using it as a log isn't feasible anymore. You could just throw it away, and nothing will change in your workflow / ability to recover from bad code changes / ability to transfer patches across versions etc.

Re: Taskfile: A Modern Alternative to Makefile

#219
post #159

Earlier quoted context omitted.

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…

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…

[dead]

Re: Taskfile: A Modern Alternative to Makefile

#220
post #44
post #21

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

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…

> That is not the argument though.

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.

Post reply on HN