Invisible <voi### [at] devnull> wrote:
>     "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.)

> 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.

If diamond inheritance is the problem, then forbid diamond inheritance.
It's not that hard. Just make the compiler say "sorry, the parent classes
cannot inherit from the same class".

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

> 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. (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.)

> People have criticised OOP for being ad hoc and lacking a coherent 
> theoretical foundation many times, of course. There was a time (around 
> about 1998 or so) when I thought that OOP was the ultimate answer to 
> every possible coding problem, and it was the way of the future. Today, 
> it just looks overly complex and ill thought out. Especially when 
> looking at something like C#.

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).

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

-- 
                                                          - Warp

Post a reply to this message

>>      "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

>> I think perhaps my biggest criticism of C# is that there doesn't seem
>> to be
>> an introduction anywhere. I can read about isolated features of the
>> language
>> on MSDN, but nowhere can I seem to find a coherent introduction...
>
>
> http://en.wikibooks.org/wiki/C_Sharp_Programming
>
> Second or third hit on google: free book.

And yet, not on any official Microsoft site. Weird, eh? (Especially when 
you consider the extensive Java tutorials available from Sun.)

> Otherwise, drop by the book store and browse around until you find one
> you like. The language is popular enough for there to be dozens in any
> given store.

Yeah, I just lost my job. I'm not really in the mood to spend £80+ on 
something that I might not even need...

(I still remember reading my dad's C++ book. That sucked so much!)

Post a reply to this message

On 13/08/2012 03:50 PM, Darren New wrote:
> On 8/13/2012 4:56, Invisible wrote:
>> OTOH, C# does that thing that C++ does where it's impossible to
>> override a
>> method, unless you manually declare it as "virtual".
>
> You can override it. You just don't get virtual dispatch.

I know that's what C++ does. But I got the impression that in C# this is 
a compile-time error. (Not that I can find any definitive word on this, 
mind you...)

>> It's true that having non-virtual methods introduces a tiny performance
>> benefit.
>
> That has nothing to do with why it was done that way, since the JIT
> removes the virtual dispatch from virtual functions you don't override.

Does that actually work? Given that you can load arbitrary new 
subclasses at any moment?

>> And then we get into access specifications. Java has public, private,
>> protected and package-local (which is implicit, and cannot be written
>> explicitly). C++ has... well, I'm not even sure /what/ the hell C++
>> has! And C# has the whole cake shop.
>
> Really, I think that's pretty much it. The same as Java, except instead
> of "package" you have "assembly". Oh, and you can put two of the
> somewhat-private declarations together. (protected assembly or something?)

You have "internal", which means "everything else in this assembly". You 
also have "protected internal", which means protected OR internal. 
(Because protected AND internal would just be nonsensical...) I'm still 
trying to wrap my brain around that last... but presumably you almost 
never need it anyway. After all, most things are just public or private.

No, wait! >_< Damnit, I meant protected...

>> You can't make something public if it refers to private types. And so on.
>
> Yes. Well, what would you expect? A public method that returns a value
> of a type you can't see the declaration of?

Haskell lets you do exactly that, yes.

> When you see the formal definitions of what you can and can't do, think
> about what it *means* and it will be clearer.

The rules are set up to make the obvious things work. My complaint is 
that due to the complexity of the system, "the obvious thing" is 
actually very difficult to codify precisely. Which is usually the sign 
of a bad design.

> Admittedly the resolution rules are pretty complicated. In practice, it
> almost never comes into play, just like in practice people don't declare
> the same name to mean different things in similar classes.

> C# has the hindsight of a bunch of OOP development. It's really not that
> complex, unless you try to learn the rules without understanding them.

I guess I'm just spoiled. In Haskell, there are precisely 2 sorts of 
type; everything is either an algebraic data type or a function type. C# 
has 5 of fundamentally different sorts of type, all with different 
semantics.

I especially love how enumerations are a different type but no, not 
really, because obviously they're actually just integers... Or how 
"bool" isn't an enumeration, it's hard-coded. Or how you can make 
primitive types nullable, but you can't make reference types 
non-nullable. Or...

> It's an excellent language in its class.

I SEE WHAT YOU DID THERE.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> > 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...)

Does what?

> I would have thought the indirect code jump is probably far more 
> expensive than the space overhead.

The additional space consumption is significant if you have eg. a class
that would otherwise be the size of a pointer (and you need to instantiate
millions of them). If you had forced virtual functions, it would double in
size.

> 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...

How would you implement a GUI library without using any kind of inheritance?

> > 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...)

But C# shouldn't have the same problems as Java. Mostly.

-- 
                                                          - Warp

Post a reply to this message

Le 13/08/2012 18:22, Orchid Win7 v1 nous fit lire :
>>
>> 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

Yep. You have the sames as me. 2000 & XP. Now only XP. Everywhere. Some
SP3, not all...
(and sometime a few 2008-R2 in 64bits servers...)
At least itanium is dead (or might... Oracle has been ordered to
continue software support, for HP...), so Windows on itanium is dead.

Vista, 7, 8... who cares, XP runs!

Post a reply to this message

Le 13/08/2012 19:26, Warp nous fit lire :
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>>> 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...)
> 
> Does what?

Manage inheritances, including multiple inheritances.

> 
>> I would have thought the indirect code jump is probably far more 
>> expensive than the space overhead.
> 
> The additional space consumption is significant if you have eg. a class
> that would otherwise be the size of a pointer (and you need to instantiate
> millions of them). If you had forced virtual functions, it would double in
> size.

IIRC, C++ does not duplicates the class function members (not even
pointers to them) in each instance. Only the actual class (as 1 pointer)
is stored within each instance. The virtual function is just an index.
The first virtual/inheritance cost a pointer in the class. The next are
free.(in fact, with RTTI, even without inheritance, you might already
have that pointer: so no additional cost)

Post a reply to this message

Am 13.08.2012 18:31, schrieb Orchid Win7 v1:
> On 13/08/2012 03:50 PM, Darren New wrote:
>> On 8/13/2012 4:56, Invisible wrote:
>>> OTOH, C# does that thing that C++ does where it's impossible to
>>> override a
>>> method, unless you manually declare it as "virtual".
>>
>> You can override it. You just don't get virtual dispatch.
>
> I know that's what C++ does. But I got the impression that in C# this is
> a compile-time error. (Not that I can find any definitive word on this,
> mind you...)

AFAIK it is a compile-time error, unless you explicitly specify that you 
DO want to override it.

C# has a lot of these "if you DO mean it, say so in the code" things. 
Which I, personally, think is pretty smart.

>>> You can't make something public if it refers to private types. And so
>>> on.
>>
>> Yes. Well, what would you expect? A public method that returns a value
>> of a type you can't see the declaration of?
>
> Haskell lets you do exactly that, yes.

I /think/ you should avoid trying to compare maintream languages' 
features to those of Haskell.

Post a reply to this message

Am 13.08.2012 18:22, schrieb Orchid Win7 v1:

>> 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?

I suspect it's because if you restrict multiple inheritance to classes 
without data members (which is essentially what interfaces are), you can 
keep inherited classes' data structure layout fully compatible with 
their parents' without additional overhead.

Otherwise, I suspect you'd need some indirection similar to a virtual 
method table for the data as well - a virtual data member table, so to 
speak.

As current widespread belief is that virtually all multiple inheritance 
use cases can be covered with the interface approach, it seems to make 
sense to avoid this extra overhead.

Post a reply to this message

Am 13.08.2012 19:26, schrieb Warp:

>> 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...
>
> How would you implement a GUI library without using any kind of inheritance?

By using /interfaces/ maybe?

You can argue that a class that implements an interface effectively 
"inherits" from it, but you can also argue against it. It's a matter of 
how exactly you define "inheritance".

Post a reply to this message