Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

221–223 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#221
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…

devenv.sh uses Nix, not Guile.

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.

Re: Taskfile: A Modern Alternative to Makefile

#222
post #87

Earlier quoted context omitted.

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

To be fair, yaml has a form of inheritance, I wouldn't define it a relatively simple format

Re: Taskfile: A Modern Alternative to Makefile

#223
post #163

Earlier quoted context omitted.

Python has no standard and the language implemented by the reference compiler is a moving target. (E.g. every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2.). The ecosystem in general is similarly dynamic. It's common to install a set of specific versioned packages and Python interpreter to get a package running.…

> every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2 People had 15 years to move from 2 to 3. I had to port dodo files from 2 to 3, it's a 10 minutes job. Most of the time, running 2to3 on it does the job automatically. After all, you only use the stlib for task runners, delegating a lot of work to bash, and they…

And yet, almost every random python script I come across does not work on my system, either because of modules or installation layout differences between the authors system and mine, or the passage of a mere few months or a year of time.

They are usually fixable of course. Assuming the thing worked on the authors system at all, it's possible to diagnose and fix it up for the current environment. But that has to be done, and sometimes takes more than a few minutes to hunt everything down.

And then one day I started seeing these pyc directories appearing out of the blue, right in whatever directory any script happened to be in. The same scripts that didn't do that yesterday. What an awesome thoughtfully engineered system!

The argument was not terrible, it was plain lived experience fact.

Post reply on HN