4 ms·

If C wants to remain competitive against up-and-coming systems languages in the next 5 years (ahem rust), we need something like this. Half of the packages in a

If C wants to remain competitive against up-and-coming systems languages in the next 5 years (ahem rust), we need something like this. Half of the packages in any linux distro would be straight-C packages in a sane universe. I understand the counterargument that 'C compiles to every architecture' and that's the key to its persistence, but hard-to-use library importing is such a high bar for new developers to learn a system. All the new talent is going to use what's easy.

davexunit 11y ago
That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I've written distribution packages for a lot of free software, and the ol' ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. This is a really bad regression in software development. edit: I should note that the ./configure && make style of building a la Autotools is not C specific. I've seen other projects written in other languages use it and building their software is just as easy as a C project.
- msbarnett 11y ago
  > ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.
  - davexunit 11y ago
    It's not the job of the build system to manage dependencies. Conflating the two has contributed greatly to the packaging mess we're in today.
    - msbarnett 11y ago
      There's certainly a strong Old School mentality in the C/C++ that says that you throw code into a repository somewhere with build instructions, and if other people want to use it in their project it's on them to package it for their system and worry about coordinating, building, and installing other dependencies. There is no "language community" so much as a Debian community and an Arch community and an OS X community and a Windows community and each and every platform should attempt to "Package the World" and solve this problem in its own way. The author cares not. Count me among the New School that feels that if you want to share your code, you package it yourself, declare its dependencies in a standard way and throw it into a central, community organized place and the whole community immediately benefits from it using a standard tool that pulls down your package and its dependencies on demand, regardless of platform. Having come to the New School from the Old School, it moves so much faster, and there is infinitely less friction when it comes to sharing code. To point at an obvious example, Common Lisp post-Quicklisp is an infinitely more pleasant and vibrant community to work in than it ever was previously. Agree to disagree, I guess.
striking 11y ago
If you use Arch Linux, you get CMake files and headers for every library you can install, built right into the package, as well as all the dependencies you'll need for those packages. C/C++ with CMake is honestly a joy. It's really wonderful. The issue is that it's not the most popular thing to use right now. The hype train has wandered off into the realms of JS, Go, and Rust. A lot of money goes into super-convenient tooling for these newly relevant languages. So perhaps I've made it clearer as to why C is less popular now.
- klodolph 11y ago
  I've been using CMake off and on for years now, including recently. I feel no joy using it. The syntax is ridiculous, the semantics are worse, and the documentation is poor, even in 2016. It gets the job done, but it is a royal pain in the butt. Whenever feasible, I'll use something else. These days, that usually means writing a quick build script generator in Python. I've been around for a while, so I remember using a lot of different build tools, from monstrosities like autotools (which has good points), hand-written makefiles, to "modern" designs like Jam, SCons, NAnt. CMake is basically the least usable of all of these (except autotools), but at the same time it is the only one which solves the desired task. I wouldn't say that it's just a matter of money and popularity. C and C++ are both quite popular these days. The problem is that the tooling is so different between platforms. You want to build a shared library? Hah, the process is quite different on Windows, and there are non-trivial differences between OS X and Linux too. You need to change your header files on Windows depending on whether the library is static or dynamic, and you even need to worry about things like "who calls free()" because as soon as you make a DLL you can't be sure that the person calling your code has the same malloc that you do. With JS, Go, and Rust, the toolchain is identical on all platforms, there are no header files, et cetera. We've had decades to try and make C tooling nice and easy, and it simply hasn't happened, despite the language's overwhelming popularity. The most usable solution we've really come up with is writing C on your favorite Linux distro, where you can just apt-get whatever you want and pkg-config it into your build system. But once you want to build on OS X, you get to choose between the insanity of Homebrew or the insanity of building your own packages. On Windows, things are even harder, because suddenly all the shell scripts that propped up your build system stop working. Your experience on Arch just reflects the reality of cross-platform development: it's awesome if you can avoid it. I do most of my development on a Linux system as well and I can reasonably call it a "joy" right up to the point when I need to finish the Windows and OS X ports. I don't think that you can truly experience the horrors of CMake if you stick to Linux. Heck, on Linux, you can hand-write makefiles fairly reasonably, if you know what you're doing.
ginko 11y ago
C will be used when many of the up-and-coming systems languages are long forgotten.

davexunit 11y ago

That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I've written distribution packages for a lot of free software, and the ol' ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. This is a really bad regression in software development. edit: I should note that the ./configure && make style of building a la Autotools is not C specific. I've seen other projects written in other languages use it and building their software is just as easy as a C project.

msbarnett 11y ago
> ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.
- davexunit 11y ago
  It's not the job of the build system to manage dependencies. Conflating the two has contributed greatly to the packaging mess we're in today.
  - msbarnett 11y ago
    There's certainly a strong Old School mentality in the C/C++ that says that you throw code into a repository somewhere with build instructions, and if other people want to use it in their project it's on them to package it for their system and worry about coordinating, building, and installing other dependencies. There is no "language community" so much as a Debian community and an Arch community and an OS X community and a Windows community and each and every platform should attempt to "Package the World" and solve this problem in its own way. The author cares not. Count me among the New School that feels that if you want to share your code, you package it yourself, declare its dependencies in a standard way and throw it into a central, community organized place and the whole community immediately benefits from it using a standard tool that pulls down your package and its dependencies on demand, regardless of platform. Having come to the New School from the Old School, it moves so much faster, and there is infinitely less friction when it comes to sharing code. To point at an obvious example, Common Lisp post-Quicklisp is an infinitely more pleasant and vibrant community to work in than it ever was previously. Agree to disagree, I guess.

striking 11y ago

If you use Arch Linux, you get CMake files and headers for every library you can install, built right into the package, as well as all the dependencies you'll need for those packages. C/C++ with CMake is honestly a joy. It's really wonderful. The issue is that it's not the most popular thing to use right now. The hype train has wandered off into the realms of JS, Go, and Rust. A lot of money goes into super-convenient tooling for these newly relevant languages. So perhaps I've made it clearer as to why C is less popular now.

klodolph 11y ago
I've been using CMake off and on for years now, including recently. I feel no joy using it. The syntax is ridiculous, the semantics are worse, and the documentation is poor, even in 2016. It gets the job done, but it is a royal pain in the butt. Whenever feasible, I'll use something else. These days, that usually means writing a quick build script generator in Python. I've been around for a while, so I remember using a lot of different build tools, from monstrosities like autotools (which has good points), hand-written makefiles, to "modern" designs like Jam, SCons, NAnt. CMake is basically the least usable of all of these (except autotools), but at the same time it is the only one which solves the desired task. I wouldn't say that it's just a matter of money and popularity. C and C++ are both quite popular these days. The problem is that the tooling is so different between platforms. You want to build a shared library? Hah, the process is quite different on Windows, and there are non-trivial differences between OS X and Linux too. You need to change your header files on Windows depending on whether the library is static or dynamic, and you even need to worry about things like "who calls free()" because as soon as you make a DLL you can't be sure that the person calling your code has the same malloc that you do. With JS, Go, and Rust, the toolchain is identical on all platforms, there are no header files, et cetera. We've had decades to try and make C tooling nice and easy, and it simply hasn't happened, despite the language's overwhelming popularity. The most usable solution we've really come up with is writing C on your favorite Linux distro, where you can just apt-get whatever you want and pkg-config it into your build system. But once you want to build on OS X, you get to choose between the insanity of Homebrew or the insanity of building your own packages. On Windows, things are even harder, because suddenly all the shell scripts that propped up your build system stop working. Your experience on Arch just reflects the reality of cross-platform development: it's awesome if you can avoid it. I do most of my development on a Linux system as well and I can reasonably call it a "joy" right up to the point when I need to finish the Windows and OS X ports. I don't think that you can truly experience the horrors of CMake if you stick to Linux. Heck, on Linux, you can hand-write makefiles fairly reasonably, if you know what you're doing.

ginko 11y ago

C will be used when many of the up-and-coming systems languages are long forgotten.