Where is C# in the Programming Language Lifecycle?

Thursday, October 22, 2009

Seven years ago, Robin Sharp divided the lifecycle of a programming language into 7 phases:

Conception

Adoption

Acceptance

Maturation

Inefficiency

Deprecation

Decay

I think Robin is correct. Once a language becomes mainstream and reaches the “acceptance” phase,  it’s only a matter of time till it becomes inefficient. This is because language designers face a dilemma:

  • Keep the language stable by not adding more features

… or …

  • Add new features to the language so it evolves with contemporary practices

Both directions have drawbacks.

In the former case, the language doesn’t keep up with the industry. Since the language is not “state of the art”, it only adds friction and inefficiency to the craft of building software applications.

In the latter case, the language is constantly evolving to meet the state of the art, but also collecting baggage and extra weight along the way as practices fall out of fashion. Eventually the language is so large and complex it again carries an inherent inefficiency.

Where is C#?

Since its inception, we’ve seen the addition of generics, lambdas, and dynamic programming features to C#. These are all welcome additions for me, and make the language better.

At the same time we’ve seen the rise of new paradigms for functional and multi-threaded programming. I have to wonder if keywords like lock, volatile, and delegate are out of fashion, like skinny leather ties that only clutter up a tie rack.

Do the new features in C# 4.0, like the dynamic keyword, push the language solidly into the maturation phase? Or … after 10 years … are we passed the maturation tipping point where C# can only descend towards inefficiency?

What do you think?


Comments
gravatar Eber Irigoyen Thursday, October 22, 2009
one thing to consider is the original design of the languages, we know that languages learn from their ancestors mistakes (and C# certainly has a huge advantage here), in the case of C# I don't know how much of the features in 1, 2, 3, 4 and 5 (I've seen Anders talk about it, the whole compiler as a service thing) were conceived initially, it seems to me it has evolved so quickly because those features were planned from the very beginning and split into the different versions; I think C# is still between the general adoption and acceptance phases and that it will take a *long time for people to catch up to the full power of C#
gravatar Sergey Friday, October 23, 2009
in my opinion new features of 4(like Optional)
is the road to Hell.

lock and volatile for new programmers is like magic scrolls. :)
gravatar Kamran Shahid Friday, October 23, 2009
New features should be added but about the particular optional parameter feature I agreed with Sergey.{It makes the polymorphism understanding very odd}
gravatar Jon Limjap Friday, October 23, 2009
It's in its teens, having an identity crisis not knowing whether to stay static or become dynamic.

I will second (or third) on the Optional parameter feature. It's one of those things that makes VB suck, and now it's here to make C# suck. Annoying, really.

The dynamic direction is interesting, but I'd rather use F# or the Iron languages to enjoy the advantages of true dynamic programming.
gravatar Eduardo Friday, October 23, 2009
That's why I use VB, a timeless classic.

(Just kidding, don't jump on me)
gravatar chris hollander Friday, October 23, 2009
I'm not sure if the 7-phase lifecycle completely applies to c#, because unlike most other languages (c,c++, java, perl, etc), we can really speak to the lifecycle of the runtime and the lifecycle of the language separately. While c# might be reaching the maturation phase, the underlying runtime is in a much longer cycle, and is probably sitting somewhere between adoption and acceptance. This allows upshots like F# to come along at the conception stage of their own lifecycle, giving both the runtime and its sibling languages a shot in the arm.
gravatar Craig Andera Friday, October 23, 2009
The assumption here is that you're working with a language that can't change itself. But not ever language fits that assumption, although C# certainly does.
SomeOne Friday, October 23, 2009
I will second (or third)(or fourth) on the Optional parameter feature.
If you want that then go to VB.Net, IMHO languages should be different not only by syntax, but features as well.
I understand that if Optional Parameter makes it easy to call out to COM which has optional parameters. If it can be done without Optional Parameters (which it can) then why introduce it in the first place. I can just see it bleeding beyond that. There will start to be C# methods defined with Optional Parameters. I can see this being used to making calls out to COM, but not used to define a C# methods with Optional Parameters (polymorphism). My hopes are that SytleCop, R#, or some other syntax code analyzer will spot c# methods defined with optional parameters and say no, no. Give us some Guidance on how and where it should be used. Similar to the misuse of generic methods and extensions are getting out of hand. I see more and more articles about the miss use of generic methods and extensions foo<t>() or foo(T object).
VB.Net is there for those who *think* doing something in C# is harder or takes more code and time. This is relative because what takes on person longer or more effort will take someone else less time and effort. If you want optional parameters then use VB.Net because not having them in C# is too difficult.
Similar issue as with optional parameter is with complex numbers. Now the line is blurred between c# and F#. If C# starts to have data types that F# has then why do I need F#? Why bloat C# with something that I can get with another language?
gravatar Matt Briggs Friday, November 13, 2009
I used to be shocked at how hard java guys fought adding closures to the language, like it was the root of all evil because they weren't used to it. As of 3.5, c# people seem to be getting the same kind of blub programmer condition

var: in what world is ReallyReallyLongTypeName reallyReallyLongTypeName = new ReallyReallyLongTypeName() better then var variable = new ReallyReallyLongTypeName()? An argument can be made that var a = obtuseFunction() is a nono, and I would agree. But where I work has banned me from using var, and friends in other shops don't use var.

optional: how is overloads that pass null up to the more verbose functions clearer then default values? I have seen 7 overloads before, plus documentation, adding up to about 100 lines of pure noise. Do people just like typing, and boilerplate?

dynamic: you can introduce a really incredible amount of flexibility into a system with dynamic typing, I mean, eliminating entire layers of archetecture. There are definately cons around tooling and performance, but it is already commonly accepted that developer productivity often outweighs performance when it comes to technology and platforms. That is why we are using C# and not assembler.


I think the whole sky is falling mentality around these features is absolutely nuts, and shows a profound myopia in the people that are freaking out.

I'll end this with a quote from pg, one of the great hackers of our time that I think totally fits. Open your mind and learn more then one language, and don't be a blub programmer

"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs."
gravatar harry Saturday, January 2, 2010
hi,

First of all. Thanks very much for your useful post.

I just came across your blog and wanted to drop you a note telling you how impressed I was with the information you have posted here.

Please let me introduce you some info related to this post and I hope that it is useful for .Net community.

There is a good C# resource site, Have alook

http://www.csharptalk.com

simi
roberto Thursday, February 25, 2010
Programming languages should be simple to write and simple to read. c# is neither.
gravatar Patterson29Angela Sunday, April 4, 2010
Various people all over the world receive the loans in various banks, because this is easy.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!