4 ms·

In your MS-DOS / turbo pascal example, there are no third party dependencies. There is just the platform and the libraries that come with the product when you i

In your MS-DOS / turbo pascal example, there are no third party dependencies. There is just the platform and the libraries that come with the product when you install it, and your code built on top of that. In this scenario, you end up reinventing a lot of wheels in your own app code, although the advantage is that all the code does exactly what you want and nothing ever breaks due to some complicated dependency hell upgrades. You can do this today with any newfangled languages, just avoid third party libraries, or at least use them as a last resort, and choose options that are stable. Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable. Most of your pain is actually due to 'package managers', not build systems per se.

skissane 4y ago
> Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable. Another way to avoid autoconf is vendoring third party libraries. If they are open source, one could just use Git sub modules. You might need to call ‘./configure’ in the vendored library directory, but you don’t need to use autoconf for the application itself
- monkpit 4y ago
  > just use Git submodules Easier said than done. I have never gotten submodules to work the way I want them to, and I’ve since abandoned the idea completely.
  - pengaru 4y ago
    The UX is admittedly awful, but once you get familiar with its warts submodules are entirely usable.
    - simplotek 4y ago
      > The UX is admittedly awful, but once you get familiar with its warts submodules are entirely usable. The point is not how much effort you need to invest in getting git submodules to eventually or occasionally work. The point is whether vending the subproject as a prebuild library/package is simpler or not, or whether it requires more work or not. And it's abundantly clear that submodules are always inferior to vending packages, not to mention they are audit-friendly.
simplotek 4y ago
> Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable. It's slightly more than that. Autoconf is a Makefile generator. It was designed to do system introspection and perform sanity checks, and configure projects so that they could be built and installed in multiple platforms. It's always possible to switch back to Makefiles. You'd be foregoing sanity checks, abstractions that come for free, and you'd have to fill in the blanks left out by missing features such as what compiler I use and how to configure the compiler and how to put together Release and Debug builds and how to consume dependencies and where do I install the project. Complaining about build systems is like complaining about a high level language: you might focus on the bloat, but you completely miss the extra work you have to reinvent the wheel and have to maintain it forever.
sverhagen 4y ago
Don't avoid third-party libraries. Unless you're some sort of genius you're constantly going to be reinventing existing wheels, whether it's networking, date, time, leap years, security stuff, and so on. And do you really need your own utility folder for manipulation of strings, lists, and the likes? And as soon as there's one thing you feel isn't worth or possible to build yourself, you need a dependency after all, back to square One. So I wouldn't search a language without a package manager or a build system, but find a good one. And then you may find a language/community with decent culture around their published packages (NPM sure has had its problems there).

skissane 4y ago

> Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable. Another way to avoid autoconf is vendoring third party libraries. If they are open source, one could just use Git sub modules. You might need to call ‘./configure’ in the vendored library directory, but you don’t need to use autoconf for the application itself

monkpit 4y ago
> just use Git submodules Easier said than done. I have never gotten submodules to work the way I want them to, and I’ve since abandoned the idea completely.
- pengaru 4y ago
  The UX is admittedly awful, but once you get familiar with its warts submodules are entirely usable.
  - simplotek 4y ago
    > The UX is admittedly awful, but once you get familiar with its warts submodules are entirely usable. The point is not how much effort you need to invest in getting git submodules to eventually or occasionally work. The point is whether vending the subproject as a prebuild library/package is simpler or not, or whether it requires more work or not. And it's abundantly clear that submodules are always inferior to vending packages, not to mention they are audit-friendly.

simplotek 4y ago

> Autoconf is just a complicated system for finding and detecting third party libraries. If an application just uses the standard library, the build system can be very simple and reliable. It's slightly more than that. Autoconf is a Makefile generator. It was designed to do system introspection and perform sanity checks, and configure projects so that they could be built and installed in multiple platforms. It's always possible to switch back to Makefiles. You'd be foregoing sanity checks, abstractions that come for free, and you'd have to fill in the blanks left out by missing features such as what compiler I use and how to configure the compiler and how to put together Release and Debug builds and how to consume dependencies and where do I install the project. Complaining about build systems is like complaining about a high level language: you might focus on the bloat, but you completely miss the extra work you have to reinvent the wheel and have to maintain it forever.

sverhagen 4y ago

Don't avoid third-party libraries. Unless you're some sort of genius you're constantly going to be reinventing existing wheels, whether it's networking, date, time, leap years, security stuff, and so on. And do you really need your own utility folder for manipulation of strings, lists, and the likes? And as soon as there's one thing you feel isn't worth or possible to build yourself, you need a dependency after all, back to square One. So I wouldn't search a language without a package manager or a build system, but find a good one. And then you may find a language/community with decent culture around their published packages (NPM sure has had its problems there).