5 ms·

Author here. This was fun to write. I think there are counter-examples, but this was my main idea: When a new developer tooling innovation is discovered, n

Author here. This was fun to write. I think there are counter-examples, but this was my main idea: When a new developer tooling innovation is discovered, newer programming languages get a chance to bake that innovation into their language tooling. Doing so gives them an incremental advantage, and these increments add up over time to a better developer experience. So newer languages have one clear, well thought out way to do something, and older languages will have either many contradictory ways, or no ways at all, to do the same thing. And this makes older languages feel old.

verdverm 4y ago
I'm surprised you didn't talk about Go's novel dep management system. They have put as much thought into that design as the stdlib https://verdverm.com/go-mods/ https://verdverm.com/go-mods/ https://go.dev/ref/mod https://go.dev/ref/mod
- adamgordonbell 4y ago
  I'm not an advanced user of either but both go.mod and cargo.toml seem like great examples of well thought out approaches to a problem, where they've learned from previous languages and came up with a pretty polished solution.
  - verdverm 4y ago
    It's not the file format that's important. For one, it's the algorithm used to select the right version of a transient dependency. Go uses MVS which is a polynomial time algo, rather than requiring SAT solver (NP-complete). Go does not allow dependency versions to be specified as ranges. Second, it's all the other checks and infra behind the scenes. A serious amount of thought went into the design of a dependency system that is far more resistant to software supply chain attacks.
civilized 4y ago
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”.
Gunax 4y ago
It makes me think there isn't any reason old languages cannot adopt these. Or even, come up with a new, batteries included version. Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.
- setr 4y ago
  You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved. Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily
  - aninteger 4y ago
    > My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
    - setr 4y ago
      That’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target. Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk. So why am I migrating?
oaiey 4y ago
There are some absolutism in there which are not correct > Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard. As a .NET developer I can just laugh here. Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case. I would say the majority of platforms for application writing nowadays come like that. Which supports your argument, just that it is the norm already for a long time. To your generalized argument: i do not follow that. Yes, modern languages have the benefit of knowledge, but the old stacks are massively catching up. Package manager and libraries is a solved problem (except for C++). The most interesting aspect this should focus about are modern compilers. The ones like C# or TypeScript which expose their services (AST, type checking, etc) as language servers. Here old platforms (PHP, C++, Java, ...) have massive pains because rewriting the compiler is the opposite of fun and new languages could start like that (e.g. TypeScript).
- idoubtit 4y ago
  >> Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard. > [...] Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case. This is not my experience with Python, and even less for PHP. There are too many dark corners in the standard libraries of these languages to hold them in high respect. The standard library of PHP is an inconsistent mess, with many documentation holes. For instance, there are several ways to send HTTP queries using the PHP STL. Apart from very basic needs, the usual way is through the libCURL integrated into the STL. Unfortunately this library is just a port from C, far from a native syntax and barely documented. For any advanced usage, the developer has to read the C documentation, or switch to a non-standard library.

verdverm 4y ago

I'm surprised you didn't talk about Go's novel dep management system. They have put as much thought into that design as the stdlib https://verdverm.com/go-mods/ https://verdverm.com/go-mods/ https://go.dev/ref/mod https://go.dev/ref/mod

adamgordonbell 4y ago
I'm not an advanced user of either but both go.mod and cargo.toml seem like great examples of well thought out approaches to a problem, where they've learned from previous languages and came up with a pretty polished solution.
- verdverm 4y ago
  It's not the file format that's important. For one, it's the algorithm used to select the right version of a transient dependency. Go uses MVS which is a polynomial time algo, rather than requiring SAT solver (NP-complete). Go does not allow dependency versions to be specified as ranges. Second, it's all the other checks and infra behind the scenes. A serious amount of thought went into the design of a dependency system that is far more resistant to software supply chain attacks.

civilized 4y ago

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”.

Gunax 4y ago

It makes me think there isn't any reason old languages cannot adopt these. Or even, come up with a new, batteries included version. Eg. keep the Java syntax, but add one standard package manager (instead of ant, mvn, gradle), one standard test framework, standard formatter, etc. Call it 'Java++' or whatever.

setr 4y ago
You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved. Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily
- aninteger 4y ago
  > My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
  - setr 4y ago
    That’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target. Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk. So why am I migrating?

oaiey 4y ago

There are some absolutism in there which are not correct > Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard. As a .NET developer I can just laugh here. Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case. I would say the majority of platforms for application writing nowadays come like that. Which supports your argument, just that it is the norm already for a long time. To your generalized argument: i do not follow that. Yes, modern languages have the benefit of knowledge, but the old stacks are massively catching up. Package manager and libraries is a solved problem (except for C++). The most interesting aspect this should focus about are modern compilers. The ones like C# or TypeScript which expose their services (AST, type checking, etc) as language servers. Here old platforms (PHP, C++, Java, ...) have massive pains because rewriting the compiler is the opposite of fun and new languages could start like that (e.g. TypeScript).

idoubtit 4y ago
>> Because of this, Go developers lean on the standard library more than many other communities and generally hold it in high regard. > [...] Compared to JS and C/C++ this is accurate, but .NET, Java, PHP, Python this is the normal case. This is not my experience with Python, and even less for PHP. There are too many dark corners in the standard libraries of these languages to hold them in high respect. The standard library of PHP is an inconsistent mess, with many documentation holes. For instance, there are several ways to send HTTP queries using the PHP STL. Apart from very basic needs, the usual way is through the libCURL integrated into the STL. Unfortunately this library is just a port from C, far from a native syntax and barely documented. For any advanced usage, the developer has to read the C documentation, or switch to a non-standard library.