Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
4  
-1: Too vague and hypothetical to be answered at all. What's "quickly"? What's "improved"? If the changes are all backward compatible, what does it matter? Please improve the question to be more specific. A concrete language which is changing quickly might help. –  S.Lott Oct 21 '11 at 2:22
    
Do the old programs still run unchanged? –  user1249 Oct 21 '11 at 7:46
4  
I certainly prefer a language which does not change at all, but is flexible enough to allow adding arbitrary new features as libraries. Huge and clumsy languages with all the features buried into their monolithic cores are doomed to rot. –  SK-logic Oct 21 '11 at 11:03
    
"Changes" and "breaks backwards compatibility" are completely different things. The latter is the real issue. –  user16764 Nov 11 '12 at 9:00
add comment

8 Answers

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.

share|improve this answer
    
C++ is not the evolution of C, it's a new language somehow compatible with C. –  Nikko Oct 21 '11 at 8:15
    
Most people don't use C++ properly, they use it like it was C since, well, they can. And, C++ when used properly is obnoxiously complex and has had a history of certain compilers not supporting all the language features. –  sylvanaar Oct 21 '11 at 11:14
    
Another key thing in favor of stability: When you're working with certified environments, language updates can be a major issue. The problem is that even for tiny patch release, the whole certification process needs to be done over from scratch each time and that's very time consuming. –  Donal Fellows Oct 21 '11 at 12:41
    
@Nikko I agree, but it is largely backwards compatible with C, which creates lots of fun problems :) –  Doug T. Oct 21 '11 at 12:42
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
C++ "evolution" is C++11, the new norm. "C#" or "D" are not C++ evolutions.. As C++ is not the evolution of C. –  Nikko Oct 21 '11 at 8:15
1  
@Nikko: Ah ha. Good point. All but a small handful of C++ programmers i know has even heard of C++0x or C++11. I'm pretty sure he wont care nor look at features unless the company upgrades compilers and happens to see something that gets them curious enough (i hope move is one of them) –  acidzombie24 Oct 21 '11 at 8:18
    
@acidzombie24: I have been programming in C++ for a long time (since 1995) and my first impression of C++11 is that it adds more complexity than real productivity to the language: the semantics of the language has become so complex that it is very easy to introduce very subtle and difficult to spot bugs. And these cost time to fix, thus reducing productivity. I might change my opinion if I am forced to really use the new standard, but even after looking at some new features in some depth my feeling hasn't improved that much. –  Giorgio Nov 10 '12 at 11:09
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.