3 ms·

Great post. Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they

Great post. Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they see it's better? Doesn't the answer just go back to the Green and Brown Language split? People who use these languages mostly work on legacy projects where they don't get to decide the tooling used. Because otherwise why would they use that language with all the trendy new options available?

adamgordonbell 4y ago
Thanks for reading. Yeah true, legacy code must be a factor. If most people in C++ are working in legacy code bases that don't leverage many thrid-party packages then I guess there is little desire to standardize on a third-party package manager. Another issue is more social. C++ has lots of package managers which is almost worse than declaring Conan the standard. Communities standards are hard to retro fit I guess? (Not to pick on C++ by the way. Every popular language eventually sees itself competing with newer incumbents. It's like the innovators dilemma for PL. )
lesam 4y ago
I’ve worked in C++ and picked my own tools. The tooling experience in Go is much more polished for a few reasons. First, as the author states, it’s hard to get consensus on a tool if it wasn’t baked in from the beginning. I don’t think there will ever be a dependency manager or especially an option-free formatter for C++ with the same adoption as gofmt or go modules. Second, it helps a lot to have the compiler/runtime authors think about the tooling. Go runtime developers think about pprof. GCC developers don’t think about the UX of valgrind. C++ standard authors don’t write PR’s for code formatting tools when they change the language spec.
- ModernMech 4y ago
  > I don’t think there will ever be a dependency manager I know a C++ guy who insists that C++ already has a dependency manager — he says it’s called Docker. Not sure I agree, but that’s the kind of attitude that seems to grow when a void exists; people get by with “good enough hack for my use case in a pinch”, and then over time that turns into “this is the way it’s done”.
  - josephg 4y ago
    C’s problem is that my “way it is done” is different from yours. Your friend uses Docker. My friend uses Apt (and hopes the libraries he wants are in there). Someone else compiles by hand and uses pkgconfig. Or CMake files. Or VC++ referenced projects. Or XCode projects. Or autotools. Or hand written make files. Or ninja. And so on. Universal tooling only has value when it’s universal. Adding yet another contender to the mess doesn’t really help unless it becomes a standard.
    - fragmede 4y ago
      Docker is orthogonal to the other tools you mentioned. You use apt or pkgconfig or autotools or hand rolled configuration inside of Docker (ignoring cross-platform issues for brevity).
twic 4y ago
I'm trying to think of examples of trying this for C or C++. * Batteries-Included Standard Library - can't actually be a standard library, but could be the next best thing, a widely-used library; things like NSPR and APR for C, or Boost for C++ * Third-Party Package Repositories - Conan, which seems to be healthy, but hasn't taken over the world * Documentation - Doxygen, which has been very successful * Write Once, Run Most Places - little progress towards this for C, but the people in the C++ standards process do at least think about portability; i think there is an inherent tension between portability and being close to the metal which means it is always going to be a lower priority for C or C++ * Package Managers - see under 'Third-Party Package Repositories'; not clear to me to what extent this is a different thing * Code Formatters - these have long existed, i suspect clang-format is most popular, but it is far from universal; what's missing is a universally-accepted strict formatting standard, as found in Go and Rust, and arguably now Python So, it seems that these things do get retrofitted, and do get adopted, but not to the same extent as if they were there from the beginning of the language.
- chakkepolja 4y ago
  CMake, sanitizers and more static analysis tooling has seen good adoption. Yeah progress has been slower than new languages but improving.
cercatrova 4y ago
That's basically what the Laravel stack does for PHP. It's great, very ergonomic, I'd use it all the time if not for having to write PHP which I don't wish to do anymore.
saghm 4y ago
> Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they see it's better? I think the first two steps sometimes happen, but the last one is where things get stuck. Often times a better experience means incompatibility with the previous solutions, so adoption happens slowly if at all. Then eventually yet another incompatible solution comes out, and things fragment.

adamgordonbell 4y ago

Thanks for reading. Yeah true, legacy code must be a factor. If most people in C++ are working in legacy code bases that don't leverage many thrid-party packages then I guess there is little desire to standardize on a third-party package manager. Another issue is more social. C++ has lots of package managers which is almost worse than declaring Conan the standard. Communities standards are hard to retro fit I guess? (Not to pick on C++ by the way. Every popular language eventually sees itself competing with newer incumbents. It's like the innovators dilemma for PL. )

lesam 4y ago

I’ve worked in C++ and picked my own tools. The tooling experience in Go is much more polished for a few reasons. First, as the author states, it’s hard to get consensus on a tool if it wasn’t baked in from the beginning. I don’t think there will ever be a dependency manager or especially an option-free formatter for C++ with the same adoption as gofmt or go modules. Second, it helps a lot to have the compiler/runtime authors think about the tooling. Go runtime developers think about pprof. GCC developers don’t think about the UX of valgrind. C++ standard authors don’t write PR’s for code formatting tools when they change the language spec.

ModernMech 4y ago
> I don’t think there will ever be a dependency manager I know a C++ guy who insists that C++ already has a dependency manager — he says it’s called Docker. Not sure I agree, but that’s the kind of attitude that seems to grow when a void exists; people get by with “good enough hack for my use case in a pinch”, and then over time that turns into “this is the way it’s done”.
- josephg 4y ago
  C’s problem is that my “way it is done” is different from yours. Your friend uses Docker. My friend uses Apt (and hopes the libraries he wants are in there). Someone else compiles by hand and uses pkgconfig. Or CMake files. Or VC++ referenced projects. Or XCode projects. Or autotools. Or hand written make files. Or ninja. And so on. Universal tooling only has value when it’s universal. Adding yet another contender to the mess doesn’t really help unless it becomes a standard.
  - fragmede 4y ago
    Docker is orthogonal to the other tools you mentioned. You use apt or pkgconfig or autotools or hand rolled configuration inside of Docker (ignoring cross-platform issues for brevity).

twic 4y ago

I'm trying to think of examples of trying this for C or C++. * Batteries-Included Standard Library - can't actually be a standard library, but could be the next best thing, a widely-used library; things like NSPR and APR for C, or Boost for C++ * Third-Party Package Repositories - Conan, which seems to be healthy, but hasn't taken over the world * Documentation - Doxygen, which has been very successful * Write Once, Run Most Places - little progress towards this for C, but the people in the C++ standards process do at least think about portability; i think there is an inherent tension between portability and being close to the metal which means it is always going to be a lower priority for C or C++ * Package Managers - see under 'Third-Party Package Repositories'; not clear to me to what extent this is a different thing * Code Formatters - these have long existed, i suspect clang-format is most popular, but it is far from universal; what's missing is a universally-accepted strict formatting standard, as found in Go and Rust, and arguably now Python So, it seems that these things do get retrofitted, and do get adopted, but not to the same extent as if they were there from the beginning of the language.

chakkepolja 4y ago
CMake, sanitizers and more static analysis tooling has seen good adoption. Yeah progress has been slower than new languages but improving.

cercatrova 4y ago

That's basically what the Laravel stack does for PHP. It's great, very ergonomic, I'd use it all the time if not for having to write PHP which I don't wish to do anymore.

saghm 4y ago

> Now, why can't someone just come up with a great tooling system for a "dreaded" language, put it out there, and everyone start using that when they see it's better? I think the first two steps sometimes happen, but the last one is where things get stuck. Often times a better experience means incompatibility with the previous solutions, so adoption happens slowly if at all. Then eventually yet another incompatible solution comes out, and things fragment.