If a language changes quickly, is this considered a good thing?

Question

I have seen some languages that change quickly (I mean they are improved every year for example) and some others that are improved slowly.

My question, if a language changes quickly is this a good thing or a bad thing for the programmer? Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?

Answer 1

if a language changes quickly is this a good thing or a bad thing for the programmer?

Good

• The changes might add some nice syntatic sugar making future code easier to write with fewer bugs
• The changes may standardize a common idiom/design pattern that programmers have had to implement themselves or rely on 3rd parties for.
• The changes may make it easier to integrate with technologies the language is typically used with
• The changes may help prevent common mistakes
• The changes may deprecate or eliminate dangerous programming practices
• The changes may have useful additions to the language's standard library for stuff I used to have to implement myself or rely on 3rd parties for.

Bad

• The language has added complexity -- new features may not always play well with the legacy features (ie C++'s relationship to C)
• Legacy code may be out of date and may no longer work in the new version of the language without updates (Python 2.x -> 3.x)
• Compilers and other tools for the language need to be updated. Now potentially multiple versions exist.
• 3rd party libraries may not support the newer version of the language
• Despite the existence of a standard, it may take time to find a standard/normal way to implement new features and define some of the more obscure cases of their behavior

Do programmers like to learn new thing in the language or do they prefer to stick with what they already know?

Many programmers enjoy satisfying their curiosity by playing with the new features. However this does not mean that the new features are always appropriate in production code. This is a case-by-case decision that has to weigh the benefits of the new features vs the cost of upgrading in one's specific situation.

I might have fun or enjoy learning about new features, but at the end of the day what I really care about is delivering a useful product to someone. I have to chose the toolset that's going to be modern enough to have reasonable support and stability but not so ancient that I can't be reasonably productive.

Answer 2

Improvements are great... if they are backwards compatible.

C# does this nicely. They add things lamdba expressions, better support for multithreading, linq,... But your five year old C# 2.0 program will still work nicely without needing any changes and can easily be upgraded to C# 4.0 without needing any changes.

Learning new stuff is great if it's allowing you to do your tasks in an easier, faster way. If spending an hour learning means saving your hours in development time, it's well worth it.

Answer 3

I want regular improvements, but I don't want it to break a 500 kloc codebase & trigger a massive "upgrade project" just to make the code work the way it does with the previous version.

Answer 4

Language stability is a must for business and for developers. Changes in the language are welcome if they solve problems or introduce features that were missed in earlier releases, but changing languages so that it is trendy or just because you want to catch-up with a competitor is not that good.

When the language is stable, over time, developers stop focusing efforts on learning the language because they would have mastered it and start focusing their efforts on serving the business with what they know. The result is shorter project, happy end users and more proud developers!

Change also comes with learning cost and time. Not all employers are willing to educate developers in new features. This adds a significant burden on the developers to train themselves or else - This is not trivial, specialized courses can be $1500-$3500 each!

Continuous change can lock developers in 'legacy' software. Take the case of ASP developer who did not catch with MVVM in 2 years from now or the case of a Windows Forms developer that did not learn WPF. This locking may hurt the developer career significantly.

Overtime, the architecture of software in a business becomes to look like a garden salad. All sorts of tools and versions and you find projects starting to do nothing but upgrading software from one version to the next without any business gain.

Answer 5

I don't think there's any one answer that's right.

Generally speaking, when a language is relatively young, there's a lot more freedom to make relatively large changes relatively quickly. There's not a large base of existing code to break, so people are generally much more open to experimentation.

As the language ages, assuming it comes into wide enough user for anybody to really care, the base of existing code starts to place tighter and tighter restrictions on what changes can be made. Not only is there more code making use of more features so it's harder to guess what changes might break code, but people's expectations change.

Just for example, let's assume there were about the same number of people writing Ruby and Fortran. Furthermore, let's assume there was about the same amount of code in both. I'd say the chances are pretty good that a change that broke exactly the same percentage of each (and in a way that took about the same work to correct) would be a lot more acceptable to Ruby users than Fortran users as a general rule (at least assuming they saw it as an improvement).

I think a lot also depends on people's perception of the language to start with. People who choose a language because it's "cutting edge" are a lot more likely to put up with major changes that break a lot of existing code, if that's what it take to keep it on the cutting edge.

Another factor is the size and life expectancy of the projects for which the language is intended. A language that caters to relatively small projects or ones we know up-front have a short life expectancy (e.g., a web UI) can get away with breaking things relatively frequently, because it's unlikely many people are going to continue using the same code base for, say, 10 years any way. A language (e.g., C++ or Java) that caters more for larger, longer lived projects that may take, say, 5 years to get to an initial release, may be in regular use (and continuous development) for three or four decades obviously demand a great deal more stability.

Answer 6

I had a guy tell me he likes his C++ and it will stay that way. He doesnt care or have interest in D, he doesnt want to know nor use C#. He learned java because he HAD to for the many projects he needed to do and he apparently does a good job in the languages he knows

Another loves C# and doesnt know every keyword or know the .NET 4 libraries (async and all) and hasnt used the abstract keywords or used attributes.

I'm simply saying most people DONT CARE

Now of the effects of the upgrade is breaking (for libs or compiled code) people WILL care.

Answer 7

I'll answer for C# (but this analysis may be applied to Scala as well):

This feature changing causes some problems when you are approaching a "style" of a language:

In 2011, C# can do a lot of different things, and this is good. Unfortunately it has two different paradigms (if not more):

• OOP
• Functional (think of lambda functions and LINQ)

Different type checking styles

• Dynamic Typing
• Static Typing

It's not always clear when you want to use one or another.

Answer 8

I think it truly depends on the language and the following that the language has. For instance, I think that if C# and Java started popping out changes in a more rapid pace that it would be accepted (as long as they are backwards compatible like Carra said). However, if the language hasn't gained traction yet and it is still changing rapidly, I know I wouldn't bother with it since there is a chance what I try to learn today will be totally different than what is out in 6 months and since the language is new/unpopular it wouldn't be detrimental to me (read: my career) for me to just pass on it.