3 ms·

One of the main features I look for in a language is stability. I just don't want it to change that much other than adding functionality to the standard library

by matt2000 7y ago

One of the main features I look for in a language is stability. I just don't want it to change that much other than adding functionality to the standard library. I know that's not the fashion currently, but it's probably one of the most valuable things to me.

bluejekyll 7y ago
Have you used Rust? Rust has made a strong guarantee to always be backward compatible. We don’t want dead languages, look at Java. It was stagnant for a long time, but has now shifted to a better delivery methodology of new language features. Rust is the same and continues to improve. Continues to make things easier and better to use without giving up its speed and low overhead goals.
- SaxonRobber 7y ago
  Why does a language need changes to be alive? We don’t ship languages, we ship code written in them. It’s like claiming wood is dead because we have vinyl.
  - geofft 7y ago
    The comment you're replying to gave a good example - the history of Java. If you're shipping code and modified code, you care about the language in which you can make those modifications. A frozen language means that either those modifications are harder (because potential improvements to the language are ignored) or they require writing components in an entirely new language and figuring out interop. (If you're not shipping modified code, then you don't care if the language changes after you ship, anyway. You shipped, and then you're done.)
    - pents90 7y ago
      > A frozen language means that either those modifications are harder I don't agree that it's harder. What is definitely harder is not being able to ship bug-fixes or modifications without ripping everything up because the language has moved on since your last release. And that is very common when developing for, as an example, iOS, since Swift is a fast-moving language that doesn't maintain backwards compatibility. The benefits of having some new language feature in Swift are far outweighed by the downside of existing codebases being invalidated. The various languages in the Javascript family suffer from this as well. The Python 2 -> Python 3 debacle was another example of this. I have dusted off 20 year old Java code which compiled and ran just fine just fine. That is extraordinarily valuable to me, and requires a lot of discipline by the language maintainers. In fact, the new faster pace of Java iteration could be its downfall, time will tell. A last note: how many language features from the past 20 years really matter? How many really speed up development, improve maintainability, etc. I would say that there are very few. In fact, perhaps the only one that passes that bar might be async/await type threading advancements.
      - geofft 7y ago
        Yeah, there's a big difference when you're targeting platforms (iOS apparently and to a lesser extent the web) that move. But if you're writing Python, Python 2 works better today than it did five years ago. The most recent Python 2-compatible version of every library that existed five years ago works at least as well as it did then, if not better. People move to Python 3 not because Python 2 is unusable - it was perfectly usable five years ago and the bits haven't disappeared from our world - but because there's lots of small things that make development easier, faster, more pleasant, and more robust. I don't think there's any single feature you can point to, but there have certainly been countless little things where, when I work on a Python 2 codebase these days, I say "I wish this were Python 3." Anyway, Rust in particular committed to indefinite backwards compatibility when they released 1.0, and the "epochs" system has been a good (post-1.0) implementation of this. They realized they wanted some keywords that they didn't reserve, some syntax that they didn't define, etc., so they said there are two epochs, 2015 and 2018. The compiler handles both, but the newer syntax only works in the 2018 epoch. If you have code that was written pre-2018, it'll keep working indefinitely, even with new compilers.
  - deleted 7y ago
    [deleted]
  - mschuetz 7y ago
    Because pre-C++11 is a nightmare to work with, but since C++11 and especially C++17, it became a somewhat enjoyable language. Similarly, pre-ES6 javascript is utter crap, but since then it became quite nice.
  - bluejekyll 7y ago
    As a software engineer, I recognize that my own code is incomplete. Will it ever be complete? Will it have all the needed features to meet ever changing demands? As the system it’s built to support grows in use, will those demands change? Languages are the same. Decisions in the past may be discovered to be incorrect in the future. Some features make the language far easier to work with and built better more stable software. In Rust there are some big ones. ?, For easier returns from functions when errors are encountered, this simplified my code, made it easier to read. async/await, vastly simplifies Future based code, based on my own experience I believe there was a 30% reduction in code when I converted old hand written Futures to the new model. These are big awesome features in Rust, that most people who use them find to be great improvements for productivity. Your attempt at an analogy is off, because neither wood nor vinyl are living things. I think if we turn to other engineering fields it’s more obvious. For example, batteries. We’ve had batteries since nearly the time that electricity was discovered. If they did not improve over the years, would we be able to build high-performance log-range cars with them? E-bikes with them? Or something else, hammers are fine for nailing things, but nail-guns are amazing. Have you ever seen someone lay top nail floors with a nail-gun? I have, and my jaw hit the floor as I watched how fast they were. I want my languages to be the same. Improve things that make the language better at working in difficult engineering spaces (for us that might be embedded), and improve it to make it more productive so I can build better software faster.
    - SaxonRobber 7y ago
      My analogy was to compare wood and vinyl as building materials for flooring (I guess I omitted that) and asking if the existence of something newer invalidates something older. I am skeptical that all language features make code better. It shifts the complexity from the code to the programmer. In order to read a piece of code, I need to potentially keep up with all of the new language features, which is a huge burden in C++. Those new features also have a tendency for complicating otherwise simple things. Like all of the edge cases that arise from objects with moving and exceptions. Sure the code might look simpler, but there is a lot more going on in the background you have to keep track of. When I write C++ now, it is typically as C with a few constexprs and templates thrown in. I try to avoid most of the new features because they just distract me from writing code that works.
at_a_remove 7y ago
I can hardly agree more with this. I program to solve problems. Changes in a language or worse, "how it is done" mean that I must keep up with something else in addition to solving the problems before me. Waves of increasing syntactic sugar in a language begin to look like layers of frippery and frosting, and I can only remember that "fashion is a form of ugliness so intolerable that we have to alter it every six months." I do not want to look at some bits of upper-row "executable line noise" that is somehow called syntactic sugar and try to have to mentally project what surface lies under that frosting. What I want is to be able to look at ten year old code and it immediately be working and understandable. I don't want it to be out to style or "uncool" or to even have to think about these things. By all means, fix bugs. Add libraries as new formats, protocols, and technologies emerge. Huge mistakes can be corrected in rare major version updates, which may have to count as actual forks in the language. When I first looked at Python, somewhere around 2004 or 2005 if I had to guess, I remember seeing that whole floor division bit and thinking, "Yeah, they're going to have to change that eventually and digging in their heels on that one was foolish." That's a rare exception, and it counts in the "why did this make it to 2.x?" category. I feel a bit lonely in this, but I just cannot seem to embrace the churn.
- ChrisSD 7y ago
  Rust isn't even five years old yet (its birthday is in May). It's not entirely surprising that it has gained a few major features in its early years that weren't ready for the 1.0 release, or were found to be useful once more people had actually started using the language.
  - at_a_remove 7y ago
    Oh, absolutely. It's that sort of thing that has pushed me in the direction of, if there's no other pressing reason to adopt a language, selecting those which have been stable for a while.

bluejekyll 7y ago

Have you used Rust? Rust has made a strong guarantee to always be backward compatible. We don’t want dead languages, look at Java. It was stagnant for a long time, but has now shifted to a better delivery methodology of new language features. Rust is the same and continues to improve. Continues to make things easier and better to use without giving up its speed and low overhead goals.

SaxonRobber 7y ago
Why does a language need changes to be alive? We don’t ship languages, we ship code written in them. It’s like claiming wood is dead because we have vinyl.
- geofft 7y ago
  The comment you're replying to gave a good example - the history of Java. If you're shipping code and modified code, you care about the language in which you can make those modifications. A frozen language means that either those modifications are harder (because potential improvements to the language are ignored) or they require writing components in an entirely new language and figuring out interop. (If you're not shipping modified code, then you don't care if the language changes after you ship, anyway. You shipped, and then you're done.)
  - pents90 7y ago
    > A frozen language means that either those modifications are harder I don't agree that it's harder. What is definitely harder is not being able to ship bug-fixes or modifications without ripping everything up because the language has moved on since your last release. And that is very common when developing for, as an example, iOS, since Swift is a fast-moving language that doesn't maintain backwards compatibility. The benefits of having some new language feature in Swift are far outweighed by the downside of existing codebases being invalidated. The various languages in the Javascript family suffer from this as well. The Python 2 -> Python 3 debacle was another example of this. I have dusted off 20 year old Java code which compiled and ran just fine just fine. That is extraordinarily valuable to me, and requires a lot of discipline by the language maintainers. In fact, the new faster pace of Java iteration could be its downfall, time will tell. A last note: how many language features from the past 20 years really matter? How many really speed up development, improve maintainability, etc. I would say that there are very few. In fact, perhaps the only one that passes that bar might be async/await type threading advancements.
    - geofft 7y ago
      Yeah, there's a big difference when you're targeting platforms (iOS apparently and to a lesser extent the web) that move. But if you're writing Python, Python 2 works better today than it did five years ago. The most recent Python 2-compatible version of every library that existed five years ago works at least as well as it did then, if not better. People move to Python 3 not because Python 2 is unusable - it was perfectly usable five years ago and the bits haven't disappeared from our world - but because there's lots of small things that make development easier, faster, more pleasant, and more robust. I don't think there's any single feature you can point to, but there have certainly been countless little things where, when I work on a Python 2 codebase these days, I say "I wish this were Python 3." Anyway, Rust in particular committed to indefinite backwards compatibility when they released 1.0, and the "epochs" system has been a good (post-1.0) implementation of this. They realized they wanted some keywords that they didn't reserve, some syntax that they didn't define, etc., so they said there are two epochs, 2015 and 2018. The compiler handles both, but the newer syntax only works in the 2018 epoch. If you have code that was written pre-2018, it'll keep working indefinitely, even with new compilers.
- deleted 7y ago
  [deleted]
- mschuetz 7y ago
  Because pre-C++11 is a nightmare to work with, but since C++11 and especially C++17, it became a somewhat enjoyable language. Similarly, pre-ES6 javascript is utter crap, but since then it became quite nice.
- bluejekyll 7y ago
  As a software engineer, I recognize that my own code is incomplete. Will it ever be complete? Will it have all the needed features to meet ever changing demands? As the system it’s built to support grows in use, will those demands change? Languages are the same. Decisions in the past may be discovered to be incorrect in the future. Some features make the language far easier to work with and built better more stable software. In Rust there are some big ones. ?, For easier returns from functions when errors are encountered, this simplified my code, made it easier to read. async/await, vastly simplifies Future based code, based on my own experience I believe there was a 30% reduction in code when I converted old hand written Futures to the new model. These are big awesome features in Rust, that most people who use them find to be great improvements for productivity. Your attempt at an analogy is off, because neither wood nor vinyl are living things. I think if we turn to other engineering fields it’s more obvious. For example, batteries. We’ve had batteries since nearly the time that electricity was discovered. If they did not improve over the years, would we be able to build high-performance log-range cars with them? E-bikes with them? Or something else, hammers are fine for nailing things, but nail-guns are amazing. Have you ever seen someone lay top nail floors with a nail-gun? I have, and my jaw hit the floor as I watched how fast they were. I want my languages to be the same. Improve things that make the language better at working in difficult engineering spaces (for us that might be embedded), and improve it to make it more productive so I can build better software faster.
  - SaxonRobber 7y ago
    My analogy was to compare wood and vinyl as building materials for flooring (I guess I omitted that) and asking if the existence of something newer invalidates something older. I am skeptical that all language features make code better. It shifts the complexity from the code to the programmer. In order to read a piece of code, I need to potentially keep up with all of the new language features, which is a huge burden in C++. Those new features also have a tendency for complicating otherwise simple things. Like all of the edge cases that arise from objects with moving and exceptions. Sure the code might look simpler, but there is a lot more going on in the background you have to keep track of. When I write C++ now, it is typically as C with a few constexprs and templates thrown in. I try to avoid most of the new features because they just distract me from writing code that works.

at_a_remove 7y ago

I can hardly agree more with this. I program to solve problems. Changes in a language or worse, "how it is done" mean that I must keep up with something else in addition to solving the problems before me. Waves of increasing syntactic sugar in a language begin to look like layers of frippery and frosting, and I can only remember that "fashion is a form of ugliness so intolerable that we have to alter it every six months." I do not want to look at some bits of upper-row "executable line noise" that is somehow called syntactic sugar and try to have to mentally project what surface lies under that frosting. What I want is to be able to look at ten year old code and it immediately be working and understandable. I don't want it to be out to style or "uncool" or to even have to think about these things. By all means, fix bugs. Add libraries as new formats, protocols, and technologies emerge. Huge mistakes can be corrected in rare major version updates, which may have to count as actual forks in the language. When I first looked at Python, somewhere around 2004 or 2005 if I had to guess, I remember seeing that whole floor division bit and thinking, "Yeah, they're going to have to change that eventually and digging in their heels on that one was foolish." That's a rare exception, and it counts in the "why did this make it to 2.x?" category. I feel a bit lonely in this, but I just cannot seem to embrace the churn.

ChrisSD 7y ago
Rust isn't even five years old yet (its birthday is in May). It's not entirely surprising that it has gained a few major features in its early years that weren't ready for the 1.0 release, or were found to be useful once more people had actually started using the language.
- at_a_remove 7y ago
  Oh, absolutely. It's that sort of thing that has pushed me in the direction of, if there's no other pressing reason to adopt a language, selecting those which have been stable for a while.