5 ms·

Exactly! When I first read the passage about libtool I thought it was a joke, and the illusion of order got a cold reality shower: > the tests elaborately exp

Exactly! When I first read the passage about libtool I thought it was a joke, and the illusion of order got a cold reality shower: > the tests elaborately explore the functionality of the complex solution for a problem that should not exist in the first place. Even more maddening is that 31,085 of those lines are in a single unreadably ugly shell script called configure. The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with.

kuschku 9y ago
And in the modern JS ecosystem, everything got even worse. With webpack, babel, TS, grunt, gulp, and all together, thousands of tools just glued together. In the Java world, at least, every few years everyone rewrites the tooling from scratch, so wehad running javac by yourself be replaced by ant, ant by maven, maven by gradle. But, that's it. In the JS world, you see nodejs launch a python script launch a ruby program launch a perl wrapper for a shell script launching another nodeJS process (e.g. during preprocessing of templates). You end up with configs that are copy pasted because no one can exactly explain how all the tools work together, much less configure it. In the C/C++ world everything got a bit better once we got CMake and Ninja, now CMake builds one file, which ninja then reads, and based on which it executes G++. Bazel/Blaze even removes this intermediate step entirely.
- couchand 9y ago
  Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). Sometimes there are npm packages that are just wrappers for other projects, but those are usually short-lived and end up being rewritten in JS (except for C/C++ libraries, which neatly compile to native extensions directly). If anything, the common complaint is much more accurate: the tooling is rewritten from scratch too often.
  - kuschku 9y ago
    > Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). How is that relevant? The problem is still that you end up with tools wrapped around tools wrapped around tools. Building a usual nodeJS project ends up with the callstack in my process explorer being 20 levels deep, of node processes, some bash mixed in, and inbetween ruby, python etc for building the documentation with mkdocs and the SASS or SCSS
  - philipodonnell 9y ago
    Eh. Anything that stands between the raw code you write and the code running on the production serer is a "tool" that has to be managed, configured, etc... The implementation language isn't as important as the fact that the code you wrote requires tools written by third parties executing a sequence of intermediate steps to be in an executable form.
    - couchand 9y ago
      Good point, we shoud all just arrange bits of machine code.
      - kuschku 9y ago
        No, but ideally you’d have 1 program you execute to transform your code into the final build, and that’s it. Maybe that program can be modular, but that’s it. Instead of precompiling Typescript and JSX to ES5, with Babel that to ES4, then launching dozens of asset processors to turn your SASS, SCSS, and JSS into CSS, with dozens of wrapped processes... As mentioned, the Java world handles everything with 2 processes, the C++ world with 3. Only the JS world manages to run in a single project webpack, gulp, grunt, compass, typescript, babel, and JSX, all transforming the source, leading to build times second only to old-school C++ projects.

kuschku 9y ago

And in the modern JS ecosystem, everything got even worse. With webpack, babel, TS, grunt, gulp, and all together, thousands of tools just glued together. In the Java world, at least, every few years everyone rewrites the tooling from scratch, so wehad running javac by yourself be replaced by ant, ant by maven, maven by gradle. But, that's it. In the JS world, you see nodejs launch a python script launch a ruby program launch a perl wrapper for a shell script launching another nodeJS process (e.g. during preprocessing of templates). You end up with configs that are copy pasted because no one can exactly explain how all the tools work together, much less configure it. In the C/C++ world everything got a bit better once we got CMake and Ninja, now CMake builds one file, which ninja then reads, and based on which it executes G++. Bazel/Blaze even removes this intermediate step entirely.

couchand 9y ago
Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). Sometimes there are npm packages that are just wrappers for other projects, but those are usually short-lived and end up being rewritten in JS (except for C/C++ libraries, which neatly compile to native extensions directly). If anything, the common complaint is much more accurate: the tooling is rewritten from scratch too often.
- kuschku 9y ago
  > Your argument isn't internally consistent. Webpack, Babel, TypeScript, Grunt, and Gulp are all implemented in JS (or TS for TS). How is that relevant? The problem is still that you end up with tools wrapped around tools wrapped around tools. Building a usual nodeJS project ends up with the callstack in my process explorer being 20 levels deep, of node processes, some bash mixed in, and inbetween ruby, python etc for building the documentation with mkdocs and the SASS or SCSS
- philipodonnell 9y ago
  Eh. Anything that stands between the raw code you write and the code running on the production serer is a "tool" that has to be managed, configured, etc... The implementation language isn't as important as the fact that the code you wrote requires tools written by third parties executing a sequence of intermediate steps to be in an executable form.
  - couchand 9y ago
    Good point, we shoud all just arrange bits of machine code.
    - kuschku 9y ago
      No, but ideally you’d have 1 program you execute to transform your code into the final build, and that’s it. Maybe that program can be modular, but that’s it. Instead of precompiling Typescript and JSX to ES5, with Babel that to ES4, then launching dozens of asset processors to turn your SASS, SCSS, and JSS into CSS, with dozens of wrapped processes... As mentioned, the Java world handles everything with 2 processes, the C++ world with 3. Only the JS world manages to run in a single project webpack, gulp, grunt, compass, typescript, babel, and JSX, all transforming the source, leading to build times second only to old-school C++ projects.