7 ms·

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 o

by amno 3y ago

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.

emptysongglass 3y ago
devenv.sh uses Nix, not Guile.
- amno 3y ago
  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.
tjoff 3y ago
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.
- deleted 3y ago
  [deleted]
- inopinatus 3y ago
  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.
- amno 3y ago
  > 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.
taspeotis 3y ago
Can you use spaces in filenames with GNU make yet? Seems like a 47yo vestige when spaces in filenames weren’t really a thing…
- colonwqbang 3y ago
  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.
- rwmj 3y ago
  Does this suffer from all the common problems with yaml (like the "Norway problem", but many others)?
  - R0flcopt3r 3y ago
    What is the "Norway problem"?
    - signa11 3y ago
      “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,…]’
      - throwaway83i3r 3y ago
        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.
        3y ago
ModernMech 3y ago
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.
- Towaway69 3y ago
  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.
  - dagmx 3y ago
    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.
    - Brian_K_White 3y ago
      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.
      - dagmx 3y ago
        FWIW, both piloting and surgery have easy on ramps in guided settings, often with simulations. So even as a strawman analogies, they’re bad ones. Nevermind that you ignored the part where I delineated between learning and using it in important projects. I’m not even going to address the rest of your comment which is frankly a depressing outlook on life.

by amno 3y ago

emptysongglass 3y ago

devenv.sh uses Nix, not Guile.

amno 3y ago
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.

tjoff 3y ago

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.

deleted 3y ago
[deleted]
inopinatus 3y ago
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.
amno 3y ago
> 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.

taspeotis 3y ago

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

colonwqbang 3y ago
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.
rwmj 3y ago
Does this suffer from all the common problems with yaml (like the "Norway problem", but many others)?
- R0flcopt3r 3y ago
  What is the "Norway problem"?
  - signa11 3y ago
    “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,…]’
    - throwaway83i3r 3y ago
      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.
      - 3y ago

ModernMech 3y ago

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.

Towaway69 3y ago
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.
- dagmx 3y ago
  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.
  - Brian_K_White 3y ago
    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.
    - dagmx 3y ago
      FWIW, both piloting and surgery have easy on ramps in guided settings, often with simulations. So even as a strawman analogies, they’re bad ones. Nevermind that you ignored the part where I delineated between learning and using it in important projects. I’m not even going to address the rest of your comment which is frankly a depressing outlook on life.