4 ms·

I don't often say this but they should probably throw it away and rewrite it from scratch with a smaller vision. There is no part of the current code that shoul

I don't often say this but they should probably throw it away and rewrite it from scratch with a smaller vision. There is no part of the current code that should actually be kept. There is no place for a pile of Bourne, m4, and perl in today's stack.

geofft 6y ago
It's difficult because the API is m4-templated shell (configure.ac, macros) and makefiles, and so you can't easily handle any existing autoconf project without using what is effectively an implementation of m4, shell, and make. Yes, projects themselves could move to something else, but there are many options for that (mentioned in the article). I'm not sure how much value an incompatible autotools-flavored tool would have to anyone. (If you're not templating shell, there are way better flavors of build tool, anyway.) This is, incidentally, a software design lesson: if your input space is too big and you basically encourage people to see straight through your abstractions, you have no abstractions. (I'm facing this at work: we have an intricate set of homegrown makefiles that evolved over some 15 years, and make is hard to teach and debug, but it's pretty difficult to switch to anything else because we allowed people to write custom makefile rules too and there are lots of them. We can automatically convert the easy cases, which are the majority, but then we'd have two systems, which is worse.)
enriquto 6y ago
> There is no place for a pile of Bourne, m4, and perl in today's stack What do you have against m4? It's a lovely little macro language.
- db48x 6y ago
  Textual macro languages are evil. Use anything else if you have any choice in the matter.
  - db48x 6y ago
    In fact, I’m not sure that I’ve stated that strongly enough. I’ve recently written a non–trivial amount of M4 to generate Rust, and I think that M4 is worse than PHP (which I’ve also written a non–trivial amount of, sadly). https://github.com/db48x/flex/blob/retargeted-to-rust/src/rust-flex.skl https://github.com/db48x/flex/blob/retargeted-to-rust/src/ru... This kind of macro language is really the worst way to write any kind of software. It’s not maintainable, it’s not readable, there’s no way to collaborate with other developers on it. There’s no way to create abstractions, so you must keep all the details in mind at all times. You can’t put those details into a box and forget about them. It is Cthulu–esqe. It would be a chapter of The Book. Practicing M4, or any language in this family, has a permanent SAN cost. Just learning the language probably doesn’t have much cost, but even small sacrifices should not be made lightly.
    - enriquto 6y ago
      > a non–trivial amount of M4 That's horrifying, and certainly not the purpose of m4. Yet, it does not mean that m4 is not beautiful, for doing small things that would be a bit cumbersome in awk, for example. > There’s no way to create abstractions Best feature in my view. Abstractions always suck. Would you complain that there's no way to create abstractions in sed, for example?
      - db48x 6y ago
        Yes. The only use for sed (and awk) is one–liners. That you either use once and throw away or immediately assign to a shell alias so that you can reuse it, because a shell alias is a means of abstraction.
- rleigh 6y ago
  In small doses, perhaps. After having to maintain some larger M4 macro collections (for Autoconf and the Autoconf Archive), as well as using it in some work projects for code generation, I'd have to say that maintenance and testing are hard. Quoting can be painful. And it has a number of annoying limitations. In retrospect, I think it was a bad choice, and I wouldn't choose to use it again. Trying to understand what's going on with multiple levels of nested macro expansions is painful, particularly when you can't directly introspect all the intermediate expansions. When it comes to M4 usage within Autoconf, I'd happily see it dropped entirely in favour of shell functions. It's a historical implementation detail which should have been removed over a decade ago.

geofft 6y ago

It's difficult because the API is m4-templated shell (configure.ac, macros) and makefiles, and so you can't easily handle any existing autoconf project without using what is effectively an implementation of m4, shell, and make. Yes, projects themselves could move to something else, but there are many options for that (mentioned in the article). I'm not sure how much value an incompatible autotools-flavored tool would have to anyone. (If you're not templating shell, there are way better flavors of build tool, anyway.) This is, incidentally, a software design lesson: if your input space is too big and you basically encourage people to see straight through your abstractions, you have no abstractions. (I'm facing this at work: we have an intricate set of homegrown makefiles that evolved over some 15 years, and make is hard to teach and debug, but it's pretty difficult to switch to anything else because we allowed people to write custom makefile rules too and there are lots of them. We can automatically convert the easy cases, which are the majority, but then we'd have two systems, which is worse.)

enriquto 6y ago

> There is no place for a pile of Bourne, m4, and perl in today's stack What do you have against m4? It's a lovely little macro language.

db48x 6y ago
Textual macro languages are evil. Use anything else if you have any choice in the matter.
- db48x 6y ago
  In fact, I’m not sure that I’ve stated that strongly enough. I’ve recently written a non–trivial amount of M4 to generate Rust, and I think that M4 is worse than PHP (which I’ve also written a non–trivial amount of, sadly). https://github.com/db48x/flex/blob/retargeted-to-rust/src/rust-flex.skl https://github.com/db48x/flex/blob/retargeted-to-rust/src/ru... This kind of macro language is really the worst way to write any kind of software. It’s not maintainable, it’s not readable, there’s no way to collaborate with other developers on it. There’s no way to create abstractions, so you must keep all the details in mind at all times. You can’t put those details into a box and forget about them. It is Cthulu–esqe. It would be a chapter of The Book. Practicing M4, or any language in this family, has a permanent SAN cost. Just learning the language probably doesn’t have much cost, but even small sacrifices should not be made lightly.
  - enriquto 6y ago
    > a non–trivial amount of M4 That's horrifying, and certainly not the purpose of m4. Yet, it does not mean that m4 is not beautiful, for doing small things that would be a bit cumbersome in awk, for example. > There’s no way to create abstractions Best feature in my view. Abstractions always suck. Would you complain that there's no way to create abstractions in sed, for example?
    - db48x 6y ago
      Yes. The only use for sed (and awk) is one–liners. That you either use once and throw away or immediately assign to a shell alias so that you can reuse it, because a shell alias is a means of abstraction.
rleigh 6y ago
In small doses, perhaps. After having to maintain some larger M4 macro collections (for Autoconf and the Autoconf Archive), as well as using it in some work projects for code generation, I'd have to say that maintenance and testing are hard. Quoting can be painful. And it has a number of annoying limitations. In retrospect, I think it was a bad choice, and I wouldn't choose to use it again. Trying to understand what's going on with multiple levels of nested macro expansions is painful, particularly when you can't directly introspect all the intermediate expansions. When it comes to M4 usage within Autoconf, I'd happily see it dropped entirely in favour of shell functions. It's a historical implementation detail which should have been removed over a decade ago.