>>      "C# programs run on the .NET Framework, an integral component of
>> Windows"
>
>> It tickles me that by "integral component of Windows", what they
>> /actually/ means is "quarter of a gigabyte optional download". :-P
>
> Is there actually a version of Windows out there that does not come with
> the .NET libraries out-of-the-box? (I mean newer than 10 years.)

How about "the version that ALL of our production systems and every 
customer-facing system in every commercial setting I've ever seen uses"? 
You know, *that* version. :-P

>> First of all, C# does that Java thing where it doesn't actually support
>> multiple inheritance (because that's too complicated), but it /does/
>> support interfaces. *sigh*
>
> I have never quite understood the reason why C++ and Eiffel seem to be
> the only programming languages in existence that support multiple
> inheritance, while the rest of OO languages only support a highly
> crippled version of it.

I have to admit, Eiffel /does/ make the solution look very, very 
complicated. (I can't actually remember off-hand how the heck C++ does 
it...)

> And it's not like diamond inheritance is forbidden with interfaces (AFAIK,
> although I haven't checked this.)

If interfaces aren't allowed to inherit anything, then a diamond is 
impossible.

Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus 
defeating the whole point of the exercise.

My conclusion: WTF?

>> OTOH, C# does that thing that C++ does where it's impossible to override
>> a method, unless you manually declare it as "virtual". This violates one
>> of the ideas behind OO, which is that if you've got a class that does
>> nearly what you want, but not quite, you can subclass it and change it
>> to make it do what you want. Well, no you can't, not if some of its
>> methods can't be overridden.
>
> In C++ it's because of the policy that you don't have to pay for what you
> don't use. If you make a class that needs no dynamic dispatch, then you
> don't pay the price for the (unused) dynamic dispatch.

That seems reasonable, given that C++ is intentionally a low-level, 
performance-oriented language.

It makes little to no sense in C#, a language which is already doomed to 
be horrifyingly inefficient before you've even written a single line of 
code.

> (The price is
> basically increasing the size of the class by a pointer, but even that
> can be a drag if you are writing code that should be as memory-optimized
> as possible. Also methods that could otherwise be inlined probably can't,
> if they have to do double indirection via a virtual table.)

I would have thought the indirect code jump is probably far more 
expensive than the space overhead. Something like this presumably puts a 
big bubble in your instruction pipeline, because it can't be predicted 
until you actually get there... (The lost inlining probably hurts even 
more.)

Arguably you could have the compiler detect where dynamic binding is and 
is not needed. That requires whole-program analysis, however. No problem 
for Haskell, but C# explicitly supports run-time loading of additional 
code, so there's no telling at compile-time what external code might do.

> Modular programming (the cornerstone upon which object-oriented programming
> builds upon) is so ubiquitously useful that I can't understand how any
> big project could live without it. Object-orientedness on top of it can
> be quite useful as well (because it solves problems that are quite
> complicated otherwise).

Yeah, I don't know. I'm slowly coming around to the idea that maybe we 
should forget about all this "inheritance" stuff and focus on interfaces 
as the primary thing of interest...

> But you should be liking C#. It doesn't leak memory and if it crashes, it
> tells you where and why. Probably.

The same can be said of Java. Last time I checked, there's no shortage 
of people who want to do violent things to Java. (I believe your name is 
on that list, for example...)

Post a reply to this message