4 ms·

This essay is taking the language author's perspective, but IMO the user's perspective is different and more important. I think what people mean when they say

by neolog 6y ago

This essay is taking the language author's perspective, but IMO the user's perspective is different and more important. I think what people mean when they say the language changed isn't literally "the language changed". It's actually what the user is supposed to do changed: The idioms changed. The ecosystem changed. Code that I wrote two years ago still works but it looks foreign to new developers.

brundolf 6y ago
I've never understood the need to keep code "up to date" with idioms. Most of the time idioms change incrementally; the seismic shifts I can think of a) have happened pretty much only once in a language's life, and b) were basically an admission that the original language design was bad and/or insufficient in some way. Whereas to me it seems like Rust's idiom changes have mostly been around using some new language feature to make certain cases a bit cleaner; that's about it. They've all been very cohesive and in line with the overarching philosophy, so I don't really see why the old way would look foreign to new developers.
- lmkg 6y ago
  I think it matters more for reading and collaborating than for writing. If you don't keep up to date with idioms, and your "fluent dialect" is three years out of date, this won't impact your ability to write your own code. But it might pose a barrier if you try to read someone's blog post, or use APIs from recent libraries, or contribute to a newer project. Rust has the obvious seismic shifts like async, which are rare. But the community has a decent amount of "best practice churn" in some areas, like error handling, or async frameworks.
- neolog 6y ago
  > I've never understood the need to keep code "up to date" with idioms. It helps with readability to have everything using the same idioms, and it helps with quality to have everything using the best idioms. > Most of the time idioms change incrementally Incremental changes stack up over time. > the seismic shifts I can think of a) have happened pretty much only once in a language's life, big changes happen much more often in new ecosystems > and b) were basically an admission that the original language design was bad and/or insufficient in some way. Yeah. If I'm considering whether to join a language, I want to know if they have so many unresolved problems that they're still fixing them all the time. Slowness is related to maturity.
steveklabnik 6y ago
I tried to get at this with this paragraph: > This analysis doesn’t get into something that I think is a huge deal: the ecosystem vs the language itself. I only track the Rust distribution itself here, but most Rust programmers use many, many ecosystem libraries. When people talk about churn in Rust, do they really mean the ecosystem, not the language? In some sense, doing so is correct: Rust having a small standard library means that you have to use external packages a lot. If those churn a lot, is it any better than churn in the language itself? The reason I didn't pursue this more is that this is significantly harder to both quantify and get data for. As I said, it is a very important way to think about this problem though!
- neolog 6y ago
  Packages are part of it. But also even if the packages don't change, the preferred idioms can change as the community figures stuff out.
  - steveklabnik 6y ago
    Yeah, it's all sort of the same genre of "stuff that's not, strictly speaking, the language."
geofft 6y ago
Are there any languages that are good at this? I feel like I would not enjoy deeply working with old C++ (e.g. auto_ptr), old Java (e.g., no lambdas), old Python (e.g., string formatting with %), and so forth - if I were making more than maintenance changes I'd modernize the syntax. sh hasn't changed much, but old shell scripts are usually buggy and would benefit from, say, bash arrays and the ability to assume that bash is installed. Old Perl is the most likely to be subject to the "write-only code" epithet, old HTML using tables and images for layout is certainly foreign, and I hear PHP today looks nothing like it looked back in the early '00s. I think the only languages that don't look foreign are languages that are basically no longer developed because they basically don't have new developers / new projects at all. Fortran is a good example - the language hasn't changed much since 1990, but a new developer wanting to call existing routines in Fortran (like BLAS/LAPACK) would generally use a younger and more featureful language like Python (via NumPy), R, Julia, or even MATLAB. The same class of users who would have directly used Fortran some 20-40 years ago are writing their own code in an entirely different and foreign language today. Part of the problem is that programming language design is still a very young field. Compare with musical notation, for instance. Music written a hundred years ago is perfectly readable to modern musicians; music written over about five hundred years ago in plainchant notation is learnable (a reader of modern music can pick it up in well under an hour of study, but won't be able to read it cold); music written over about a thousand years ago, is pretty unreadable without training. Meanwhile, programming languages date from the 1950s, and various language features are very new (syntactic async/await first appeared about a decade ago, for instance, and even the Liskov substitution principle is only about 26 years old). There are clear reasons to prefer the incrementally improved notations for both music and software - neither Guido d'Arezzo nor Guido van Rossum got everything right on the first try, even though their original notations are readable to practitioners today - it's just that we've already figured out musical notation we're happy with and there haven't been significant incremental improvements in music hundreds of years.
- deleted 6y ago
  [deleted]
- nyanpasu64 6y ago
  I haven't dealt with tables a lot, but I've seen a lot of sites based on absolute positioning and floats, rather than flexbox and grid. And there's been an explosion of modern (computer-based) musical notations recently... piano roll editors, MML, trackers, possibly 16-step sequencers as well...
staticassertion 6y ago
Yeah but that mostly hasn't really happened either. I've been using Rust since just before 1.0. In the first year, there was churn constantly - it used to be that, for a good experience with json, you needed nightly. It was insane. A few key features landed and things more or less stabilized in the language - I don't recall anything super meaningful where I was like "ah nice, time to update my code". We got some helpers like `impl Trait`, but there was 0 reason to go back into most codebases to use it. More recently the major change was with async/await. At this point, sure, you may want to go back to old code using old futures and update? So that's one major change in my entire time using Rust where I'd say "yeah, go back, bring stuff up to speed if you can". I guess there's the new anonymous lifetime stuff, which I don't really think was that important to add tbh. Most churn is in libraries, unsurprisingly. Tokio only just hit 1.0, but that does mean that from here on out we can expect much less churn there. idk otherwise, nothing sticks out to me as a major idiom change. I don't think Rust code 2-3 years ago will be particularly foreign at all, again with the exception for when people used to use 'raw' Futures.

by neolog 6y ago

brundolf 6y ago

I've never understood the need to keep code "up to date" with idioms. Most of the time idioms change incrementally; the seismic shifts I can think of a) have happened pretty much only once in a language's life, and b) were basically an admission that the original language design was bad and/or insufficient in some way. Whereas to me it seems like Rust's idiom changes have mostly been around using some new language feature to make certain cases a bit cleaner; that's about it. They've all been very cohesive and in line with the overarching philosophy, so I don't really see why the old way would look foreign to new developers.

lmkg 6y ago
I think it matters more for reading and collaborating than for writing. If you don't keep up to date with idioms, and your "fluent dialect" is three years out of date, this won't impact your ability to write your own code. But it might pose a barrier if you try to read someone's blog post, or use APIs from recent libraries, or contribute to a newer project. Rust has the obvious seismic shifts like async, which are rare. But the community has a decent amount of "best practice churn" in some areas, like error handling, or async frameworks.
neolog 6y ago
> I've never understood the need to keep code "up to date" with idioms. It helps with readability to have everything using the same idioms, and it helps with quality to have everything using the best idioms. > Most of the time idioms change incrementally Incremental changes stack up over time. > the seismic shifts I can think of a) have happened pretty much only once in a language's life, big changes happen much more often in new ecosystems > and b) were basically an admission that the original language design was bad and/or insufficient in some way. Yeah. If I'm considering whether to join a language, I want to know if they have so many unresolved problems that they're still fixing them all the time. Slowness is related to maturity.

steveklabnik 6y ago

I tried to get at this with this paragraph: > This analysis doesn’t get into something that I think is a huge deal: the ecosystem vs the language itself. I only track the Rust distribution itself here, but most Rust programmers use many, many ecosystem libraries. When people talk about churn in Rust, do they really mean the ecosystem, not the language? In some sense, doing so is correct: Rust having a small standard library means that you have to use external packages a lot. If those churn a lot, is it any better than churn in the language itself? The reason I didn't pursue this more is that this is significantly harder to both quantify and get data for. As I said, it is a very important way to think about this problem though!

neolog 6y ago
Packages are part of it. But also even if the packages don't change, the preferred idioms can change as the community figures stuff out.
- steveklabnik 6y ago
  Yeah, it's all sort of the same genre of "stuff that's not, strictly speaking, the language."

geofft 6y ago

Are there any languages that are good at this? I feel like I would not enjoy deeply working with old C++ (e.g. auto_ptr), old Java (e.g., no lambdas), old Python (e.g., string formatting with %), and so forth - if I were making more than maintenance changes I'd modernize the syntax. sh hasn't changed much, but old shell scripts are usually buggy and would benefit from, say, bash arrays and the ability to assume that bash is installed. Old Perl is the most likely to be subject to the "write-only code" epithet, old HTML using tables and images for layout is certainly foreign, and I hear PHP today looks nothing like it looked back in the early '00s. I think the only languages that don't look foreign are languages that are basically no longer developed because they basically don't have new developers / new projects at all. Fortran is a good example - the language hasn't changed much since 1990, but a new developer wanting to call existing routines in Fortran (like BLAS/LAPACK) would generally use a younger and more featureful language like Python (via NumPy), R, Julia, or even MATLAB. The same class of users who would have directly used Fortran some 20-40 years ago are writing their own code in an entirely different and foreign language today. Part of the problem is that programming language design is still a very young field. Compare with musical notation, for instance. Music written a hundred years ago is perfectly readable to modern musicians; music written over about five hundred years ago in plainchant notation is learnable (a reader of modern music can pick it up in well under an hour of study, but won't be able to read it cold); music written over about a thousand years ago, is pretty unreadable without training. Meanwhile, programming languages date from the 1950s, and various language features are very new (syntactic async/await first appeared about a decade ago, for instance, and even the Liskov substitution principle is only about 26 years old). There are clear reasons to prefer the incrementally improved notations for both music and software - neither Guido d'Arezzo nor Guido van Rossum got everything right on the first try, even though their original notations are readable to practitioners today - it's just that we've already figured out musical notation we're happy with and there haven't been significant incremental improvements in music hundreds of years.

deleted 6y ago
[deleted]
nyanpasu64 6y ago
I haven't dealt with tables a lot, but I've seen a lot of sites based on absolute positioning and floats, rather than flexbox and grid. And there's been an explosion of modern (computer-based) musical notations recently... piano roll editors, MML, trackers, possibly 16-step sequencers as well...

staticassertion 6y ago

Yeah but that mostly hasn't really happened either. I've been using Rust since just before 1.0. In the first year, there was churn constantly - it used to be that, for a good experience with json, you needed nightly. It was insane. A few key features landed and things more or less stabilized in the language - I don't recall anything super meaningful where I was like "ah nice, time to update my code". We got some helpers like `impl Trait`, but there was 0 reason to go back into most codebases to use it. More recently the major change was with async/await. At this point, sure, you may want to go back to old code using old futures and update? So that's one major change in my entire time using Rust where I'd say "yeah, go back, bring stuff up to speed if you can". I guess there's the new anonymous lifetime stuff, which I don't really think was that important to add tbh. Most churn is in libraries, unsurprisingly. Tokio only just hit 1.0, but that does mean that from here on out we can expect much less churn there. idk otherwise, nothing sticks out to me as a major idiom change. I don't think Rust code 2-3 years ago will be particularly foreign at all, again with the exception for when people used to use 'raw' Futures.