The Future of C#, Part Two

re: The Future of C#, Part Two

int19h — Tue, 28 Oct 2008 21:08:44 GMT

Eric,

I would really appreciate if one of you C# 4.0 gurus could take a glance at the description of new features on Wikipedia: http://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Future_development - and tell if there are some glaring mistakes there that have to be fixed for the sake of encyclopedic accuracy.

re: The Future of C#, Part Two

Eric Lippert — Tue, 28 Oct 2008 21:39:43 GMT

There are no glaring mistakes at first glance; there are a couple of very minor errors here and there.

Send me your email address and when I have a moment I'll go over the article in detail and email you my errata.

re: The Future of C#, Part Two

int19h — Tue, 28 Oct 2008 22:06:34 GMT

Thank you very much!

It's int19h@gmail.com.

re: The Future of C#, Part Two

int19h — Tue, 28 Oct 2008 22:10:48 GMT

Oh, and regarding language features - apparently, there are some puzzlers regarding dark corners of variant generics coming up already (stuff you've covered here previously, but with no definite conclusion then):

http://social.msdn.microsoft.com/Forums/en-US/vs2010ctpvbcs/thread/c1e4476d-8be8-41b3-9dae-55b834313ce6

re: The Future of C#, Part Two

cwbrandsma — Wed, 29 Oct 2008 00:25:15 GMT

"writing interfaces only intended to be implemented by one class"

Give me a built in way to mock a class (without resorting to typemock) that doesn't involve creating an interface/abstract base class, and I will gladly stop. Bonus point if you can show me this while implementing a MVP pattern (testing the Presenter).

re: The Future of C#, Part Two

Arne Claassen — Wed, 29 Oct 2008 00:28:29 GMT

Eric, I suffer from OHD, at least when it comes to the Interface portion for two reasons: Testability and build time abstraction

The first is a result of needing the interface so that i can mock my dependencies for unit testing. Can't really see a way around that. True, there will always exist at least two implementations of any interface, but it's still sort of artificial. I guess i'd put extension methods in a similar camp, since unless i attach the extension on an interface, i once again can't test it in isolation.

The latter is a result of having to recompile the entire tree of depdendent assemblies if a low level class changes even if the change is internal to the class. By keeping everything behind interfaces and the interfaces in a separate assembly, the build dependence goes away, which on large projects is a signficant time saving.

Any way around these limitations without going object and interface happy?

re: The Future of C#, Part Two

Eric Lippert — Wed, 29 Oct 2008 00:42:42 GMT

I think maybe I was not entirely clear on that point.

What I intended to get across was that I have seen codebases where every class definition also had an identical interface definition _for no good reason_.

Someone had been taught at some point that interface abstraction was A Very Good Thing, and so every time they defined a class, boom, there was a parallel interface right there too. And of course the code was then littered with casts casting values of interface types back to their corresponding class types, because after all, we know that every IFoo is actually a CFoo!

If you're writing interfaces that are designed to only be implemented by one class, and you have a really good reason for that, then that's not Object Happiness, that's working around the limitations of a tool in a fairly sensible manner.

re: The Future of C#, Part Two

Frank Quednau — Wed, 29 Oct 2008 00:58:20 GMT

@cwbrandsma

Can you not declare that virtual which you want to mock?

Anyway, thanks for that post, makes me a lot more relaxed about C#'s future! Down with philosophy! Up with pragmatism! (Only a few centuries ago, philosophers were practicians...)

re: The Future of C#, Part Two

Thomas Danecker — Wed, 29 Oct 2008 02:17:43 GMT

doesn't "makes it easy to program in a ... style" sometimes imply "and difficult (or impossible!) to program in a non-... style"?

i.e. when you want to be able to programm e.g. in oo style, you have the implicit requirement, that the things you're using (frameworks, apis, librarys) are also written in that style. otherwise it gets really difficult to use all that cool stuff that's already built in the framework while sticking to the chosen style.

I enjoy the mixture of styles in c#/.net (and love the new declarative style), but imho, contrary to your point, it makes the language less object oriented. ok, it's more the framework that is less oo, but those two things go hand in hand somehow.

re: The Future of C#, Part Two

Mark — Wed, 29 Oct 2008 02:41:29 GMT

"Can you not declare that virtual which you want to mock?"

You definitely can work around these things, but I'd imagine a lot of people find it a good bit more convenient & clear when working with interfaces, as you can guarantee that a stub/mock/testdouble/whatever won't have any kind of unwanted logic or dependencies. At work I've had a few cases where someone else's code is working off a base class and, due to things like static methods lurking within (which potentially each pull in dependencies of their own!) I've found it hard to get the tests working without a lot of aggravation. The moment they use an interface, things go a lot more smoothly. By implementing the interface in a base class, you get the best of both worlds. Same code, just an extra interface to worry about.

Like the article says, it's possible to go too far, though. I tend to make an interface for anything that has a tangible effect on my ability to test. If I am never going to need multiple versions of a class, and that class has few dependencies and little/no impact on my testing, then I don't bother. Same deal if there is no real 'common' interface and casting would be required.

Rule of thumb is simply what the article said. Don't do it just to do it. Do it because it greases the wheels and makes your job easier. Also, it helps to extract interfaces once the code is fairly stable, otherwise you just end up constantly updating code in two or three places instead of one or two).

re: The Future of C#, Part Two

themanfromsql — Wed, 29 Oct 2008 03:29:11 GMT

Eric,

Thank you for the clarification in the comments about why you wrote your article. On first read, it did sound like you were discounting OO principles out of hand. And you're right, there are some programmers who will take OO principles and apply them dogmatically and unthinkingly everywhere, just like there will always be people who will dogmatically adhere to the tenets of <insert your favorite religious or political organization>, and just like there will be people who will walk away from your article proclaiming that object-oriented programming is bad. There is still no good substitute for thinking.

re: The Future of C#, Part Two

Michael — Wed, 29 Oct 2008 04:34:31 GMT

No offense meant, but anyone who says that Scheme makes it difficult to program in an object-oriented style simply doesn't know squat about Scheme. The language does not "resist you at every turn". In fact, the language features (closures, macros) make it very easy for an average Scheme programmer to write his/her own OO system if he/she wants to. In fact, this is the real problem with OOP in Scheme: it's so easy to write an OO system that everyone writes a different one. Check out http://www.plt-scheme.org for a Scheme implementation that has a full-featured object system.

re: The Future of C#, Part Two

Greg M — Wed, 29 Oct 2008 11:08:30 GMT

I agree with Thomas, and I'll go one step further and say that it applies even more so to functional programming. One of the big advantages you get from programming functionally are the guarantees of immutability, referential transparency etc, so if you're interfacing with code written in a non-functional style then being able to write your own code in a functional style isn't going to buy you as much as it would in a purely-functional program.

re: The Future of C#, Part Two

RichB — Wed, 29 Oct 2008 11:28:14 GMT

> # writing interfaces only intended to be implemented by one class

> # designing every class to enable derivation, whether it needs it or not

All well and good, except when it comes to testability. To get great test coverage, it is necessary to mock out objects. Ultimately, the only testability feature built into C# is friend assemblies. I wish that C# was testable without having to use the above features, but it's not. Misko Hevery (testability advocate at Google) says this well in several posts on his blog:

http://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/

http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

I guess the biggest bugbear from the DI (IoC) meme is that class-based OO languages need to split the .ctor in two, into an object graph constructor and an initialization constructor.

re: The Future of C#, Part Two

int19h — Wed, 29 Oct 2008 13:38:29 GMT

> I wish that C# was testable without having to use the above features, but it's not.

TypeMock to the rescue!

... except that some TDD proponents argue against TypeMock because it "promotes bad design" (i.e., does not force you to make an interface for every class, and forcibly decouple things even where it's pointless for any purpose but unit testing). So, it's not quite so simple.

re: The Future of C#, Part Two

JScript as JavaScript — Wed, 29 Oct 2008 14:05:47 GMT

I'll just say one thing that should get an educated reader critique everything written as this was done 15 years back:

Mix-Ins.

re: The Future of C#, Part Two

Sean Mulkerrin — Wed, 29 Oct 2008 14:35:06 GMT

requesting that multiple class inheritance be added to the language

I used to have this symptom very bad, but thankfully with many years of c# therapy i've been cured. for the most part at least.

Some days are harder than others . . .

re: The Future of C#, Part Two

RichB — Wed, 29 Oct 2008 15:10:04 GMT

int19h> TypeMock looks interesting. It's an interception system using the profiler API, so I guess it slows things down, but that doesn't matter in a unit test scenario.

re: The Future of C#, Part Two

Stephan Leclercq — Wed, 29 Oct 2008 15:59:28 GMT

Ah... Multiple inheritance... I would gladly stop requesting that if I had a proper way to make mix-ins.... Right now, having a class that implements two interfaces, reuses default behaviour from both, and redefines some from both, is complicated. An OO language should make that simple, you said this yourself !

re: The Future of C#, Part Two

Pop Catalin — Wed, 29 Oct 2008 17:07:16 GMT

Regarding object happiness ... in my opinion, the true power of Linq comes not from functional programing alone, but from the fact that it can convert functional constructs to "Objects" ( Expresion<Func<...>> are objects).

How I see it is that, Objects are more flexible than functions, while functions are closed black boxes in most cases, objects are boxes with windows and doors. Generaly functions are composable, while objects can be both composable and decomposable, this is why I'm somewhat object happy in general, but I still like a functional approach where decomposition/modification is not needed or should be avoided (and very much welcome the functional aspect of C#).

Dynamic? can't say I'm I have a opinion about it yet, as I'm not a dynamic fan, maybe I would have liked more some Spec#/C(Omega) features at first sigh, but hey :) there's a place for everything, in a dynamic world (literally) even a statically typed language can make a good use of dynamic features. I'm really curious to see how dynamic will work with generics, extension methods, lambda expressions and especially Linq.

re: The Future of C#, Part Two

markus — Wed, 29 Oct 2008 18:06:51 GMT

Dont forget that there are more ways to regard objects.

Personally I use ruby, so I am much more inclined to the dynamic ways of smalltalk. I even enjoy prototype thinking in objects.

For me essentially, OOP is finally about messages mostly (that alter a state), then come the objects. I always felt that C++ overcomplicated the whole aspect behind it to the worse. The only amazing thing is that C++ was such a success compared to C, because we still see so much of C++.

This, in a way, makes me sad, because frankly C is a huge mess, especially with the whole ecosystem.

re: The Future of C#, Part Two

int19h — Wed, 29 Oct 2008 20:36:30 GMT

> For me essentially, OOP is finally about messages mostly (that alter a state), then come the objects. I always felt that C++ overcomplicated the whole aspect behind it to the worse.

Glad to see the Smalltalk "that's not what I meant when I invented the term 'OOP'!" mentality is still alive. :)

Do keep in mind though that the very first OO language was still Simula, which was very much statically typed and static overall (and C++ and the rest of the family are all recognizable descendants of Simula).

re: The Future of C#, Part Two

Greg M — Thu, 30 Oct 2008 04:46:48 GMT

@Pop:

What do you mean by decomposition in this context?

re: The Future of C#, Part Two

Pop Catalin — Fri, 31 Oct 2008 14:50:58 GMT

@Greg:

I mean that objects are inherently mutable, objects can be composed of more objects as fields (that are exposed or not) and if the object pars are exposed and mutable, then the object is decomposable, on the other hand when you compose functions you create a new function that is a black box, you can't get to it's inner parts (usually).

Community Convergence XLVII

Charlie Calvert's Community Blog — Tue, 04 Nov 2008 04:37:40 GMT

Welcome to the 47th Community Convergence. We had a very successful trip to PDC this year. In this post

re: The Future of C#, Part Two

Piyush Goriya — Mon, 10 Nov 2008 07:48:41 GMT

Welcome to the 47th community convergece. we had a very successful trip to XBOX this year in this post

re: The Future of C#, Part Two

Mark Demory — Wed, 19 Nov 2008 03:53:46 GMT

Sorry I'm late. Don't sweat it if no one reads this (OO humor).

The number one problem I've had with all Microsoft products to date (with one exception) is this: too many features!

I've been a professional engineer/programmer/etc. for 25+ years, and I've used a fair variety of Microsoft products over the years, as well as non-Microsoft software development products.

Please, please, PLEASE, if anyone at Microsoft reads this, consider changing your mind! Rather than continuing to generalize C#, give us more, more specialized, tools! The more you generalize C# the less useful it will be for me to solve problem X.

I have used a screwdriver as a chisel. It worked great! Once. But after that it only worked as a chisel. Now that I'm a little older I use the right hand tool for the job.

re: The Future of C#, Part Two

Mark Demory — Wed, 19 Nov 2008 04:00:27 GMT

I forgot to mention the good news! Sorry. My favorite computer ever (in the 25 years of using personal computers -- literally! I still own several CP/M machines which I never use).

I use an NEC MobilePro pretty much every day -- at work, at home, at church, in the car (just audio while driving, of course), at the local coffee shop after walking 30 minutes to get there, etc. That's Windows CE 3.0, which of course is my favorite single operating system ever, for mobile computing. I honestly do not need any of the additional features since, and still VERY MUCH MISS the lack of VBscripting in that one!

Kudos to KISS.

Thanks.

re: The Future of C#, Part Two

Duncan Bayne — Wed, 26 Nov 2008 02:27:06 GMT

"The techniques are not good in of themselves, they're good because they're practical."

You've actually touched upon a serious philosophical here: "inherent value" is nonsense.

Value is a relationship between a valuer and an object; it is not an inherent property like dimension or mass. For something to have value, there _must_ be a valuer.

Thus a software methodology is _in of itself_ utterly devoid of value. It might however be valuable to certain people in certain contexts. The same applies to everything in existence - trees, rocks, computers, buildings, paintings, music, even people unless they (or others) see value in themselves.

C# Dynamic - CSharp's new feature of the coming version 4.0

Journal of Abu Sayed Mohammad Ismail — Wed, 24 Dec 2008 09:38:28 GMT

Very good resources for the coming version... Sam Ng Dynamic in C# Part One Dynamic in C# Part Two Chris

re: The Future of C#, Part Two

Reineir Post — Tue, 06 Jan 2009 13:09:07 GMT

Perhaps deliberately you to not mention that language features come at a cost to everyone involved with the language, not just language designers: every user, every writer of software to support the language (compilers, syntax checkers, syntax highlighters, anything) will be faced with the possibility of meeting applications in the features, whether they like it or not.

If the feature is at least non-intrusive, they can still continue their usual ways as long as they only meet and write code that doesn't actually apply the feature; but with intrusive features, that do not just add new syntax but modify the meaning of existing constructs or even programs, they have to understand the feature in depth and revise their existing code right away. This is what is wrong with extension methods: they should have used a different syntax!

re: The Future of C#, Part Two

vishwajit — Tue, 24 Feb 2009 09:55:01 GMT

i forgot to mention the good news! Sorry. My favorite computer ever (in the 25 years of using personal computers -- literally! I still own several CP/M machines which I never use).

Kudos to KISS.