3 ms·
> "Programmers don't want a system for writing build scripts; they want a system for writing systems that write build scripts." It is a truth universally ackno
by sdenton4 6y ago
> "Programmers don't want a system for writing build scripts; they want a system for writing systems that write build scripts."
It is a truth universally acknowledged that a shitty scripting language in possession of a large user base will be in search of a new scripting language that automatically generates the shitty scripting language.
But then you have two problems.
- marcosdumay 6y agoThat's a good observation. Any deficiency in a complex, widely used and difficult to change development tool will be fixed by adding an extra layer over it. If the deficiency is something like complexity or lack of reliability that can not be fixed by adding extra layers, read this comment again.
- hoskdoug 6y agoGreat example is Fastlane abstracting over the impenetrable iOS command line tools.
- jnxx 6y agoIs that how cmake came to exist?
- rumanator 6y agoCake came into existence because all other alternatives were pure crap. And since cmake's inception, all cmake alternatives are still pure crap. The definition of "well" is relative.
- btschaegg 6y ago> And since cmake's inception, all cmake alternatives are still pure crap. …including CMake. :-) Although, to be fair, I think CMake did at least achieve to prove that creating a turing complete "jack of all trades" meta build system is not a good idea in pretty much every case (although I'd argue that boost had done that well in advance). It's too sad that with the myriad of legacy patterns around in the C/C++ build space (in production), there is pretty much 0 chance of simplifying the problem for a majority of cases instead.
- rumanator 6y agoYeah cmake is pretty crappy, and it's a shame that nothing better popped up in the last, say, 20 years. However, to be fair cmake's main problem is it's appalingly poor documentation and user experience. It's very telling that since the release of cmake 3 the main source of info on how to do cmake the right way is not anythig churned out by cmake, whose docs are pretty much unintelligible, but random blog posts that manage to put together basic idiomatic code snippets. This poor state of affairs is reflected in collaborative sources of info such as stack overflow, where well-meaning users reiterate poor or straight-out wrong ways of doing things mainly because they don't and can't know better.
- jnxx 6y ago> cmake's main problem is it's appalingly poor documentation and user experience. "I thought I was dumb until I realized it's the book". Top Amazon review of the top book on CMake. And I am still wondering whether it is the book, or the tool.
- jnxx 6y agoSo, while not just use distribution package creation and managing tools, like the Debian ones? Or even better Guix?
- btschaegg 6y agoAs I said, to me the whole thing looks like a giant log jam made of bad tools causing other bad tools and there is no simple way of cleaning up the landscape without whipping out a chainsaw and breaking existing workflows and use cases first. However, if you are in the privileged position of being able to address every use case by compiling and/or cross-compiling from a nix or Guix setup for a project, I'd certainly go with that, too. The problem there is that this is likely never the case if you can't just containerize your application or prescribe which system it will run on -- which holds true for a lot of software.
- scoot_718 6y agoThat's why I stopped using Ansible in favour of pyinfra.