4 ms·

Another language? Do you mean that Ruby, or Go, or Rust, or Javascript are less likely to force you to another jump in the next 20 years? I dislike the new pri

by gbog 10y ago

Another language? Do you mean that Ruby, or Go, or Rust, or Javascript are less likely to force you to another jump in the next 20 years? I dislike the new print in py3, but still the python community do take things seriously and are not switch horses every 6 months. I also do Javascript and, well, I'd love the community there to hold on something and actually dig it for more than 6 months.

Xylakant 10y ago
Ruby is actually a good comparison: It has the same kind of switchover, ruby 1.8 didn't support unicode while ruby 1.9 and newer does. The changes happened roughly at the same time as the py2/3 switchover, but happened much much faster. No incompatible syntax changes happened, no semi-automatic translation between 1.8 and 1.9. A lot of libraries worked (and still do) flawlessly on 1.8 and 1.9, many - including rails - offered compatibility relatively early since ruby 1.9 offered significant benefits over 1.8. There were websites and tools listing the compatibility of your favorite gems[1]. So yes, it is definitely possible to make such changes more gradual and effective both by providing the technical means and by assembling sufficient community support. [1] https://github.com/seattlerb/rubygems-isit19 https://github.com/seattlerb/rubygems-isit19
sfink 10y ago
Javascript in particular? Yes, it's less likely to force a jump. It has to stay compatible with the web as it exists today and has existed for the last 20 years. Idiomatic JS will certainly change, but that doesn't force old code to change. Ruby and Go live on the server side, so do not have nearly as harsh a backwards compatibility constraint. Come to think of it, I wonder if JS's backcompat story is precisely what has resulted in the intense rate of churn in the libraries and frameworks written in it. Maybe if the language forced periodic change, then that would both reduce the frameworks' evolutionary pressure to change, and increase frameworks' evolutionary pressure to paper over JS's changes. As it is now, the architecture seems to be that you have an unchanging language layer so you put all of the change into the next layer up. (Well, that and the client-side delivery and execution means that framework updates are far far easier than with any server-side language/framework.)

by gbog 10y ago

Xylakant 10y ago

Ruby is actually a good comparison: It has the same kind of switchover, ruby 1.8 didn't support unicode while ruby 1.9 and newer does. The changes happened roughly at the same time as the py2/3 switchover, but happened much much faster. No incompatible syntax changes happened, no semi-automatic translation between 1.8 and 1.9. A lot of libraries worked (and still do) flawlessly on 1.8 and 1.9, many - including rails - offered compatibility relatively early since ruby 1.9 offered significant benefits over 1.8. There were websites and tools listing the compatibility of your favorite gems[1]. So yes, it is definitely possible to make such changes more gradual and effective both by providing the technical means and by assembling sufficient community support. [1] https://github.com/seattlerb/rubygems-isit19 https://github.com/seattlerb/rubygems-isit19

sfink 10y ago

Javascript in particular? Yes, it's less likely to force a jump. It has to stay compatible with the web as it exists today and has existed for the last 20 years. Idiomatic JS will certainly change, but that doesn't force old code to change. Ruby and Go live on the server side, so do not have nearly as harsh a backwards compatibility constraint. Come to think of it, I wonder if JS's backcompat story is precisely what has resulted in the intense rate of churn in the libraries and frameworks written in it. Maybe if the language forced periodic change, then that would both reduce the frameworks' evolutionary pressure to change, and increase frameworks' evolutionary pressure to paper over JS's changes. As it is now, the architecture seems to be that you have an unchanging language layer so you put all of the change into the next layer up. (Well, that and the client-side delivery and execution means that framework updates are far far easier than with any server-side language/framework.)