http://www.itjobswatch.co.uk/jobs/uk/developer.do

Hmm, that's interesting...

Post a reply to this message

On 08/08/2012 03:26 PM, Invisible wrote:
> Hmm, that's interesting...

Apparently I need to learn C# then.

Post a reply to this message

http://www.itjobswatch.co.uk/jobs/uk/haskell.do

LOL.

Post a reply to this message

On 08/08/2012 09:41 PM, Orchid Win7 v1 wrote:
> Apparently I need to learn C# then.

So today, I decided to take a look at that. So far, I've been variously 
amused and horrified.

    "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

(Not only is it a quarter of a gigabyte - which, even with 5mbit 
broadband, takes quite a while to download - but it also takes about 35 
minutes to actually install the thing! And that's not counting the 
further 15 minutes where the ".NET optimisation service" is silently 
running in the background without telling you, slowing your PC down 
until you let it finish...)

Then we start to get into some of the design decisions.

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*

Oh, but we still get much of the complexity of MI, Eiffel-style. For 
those of you who've never /heard/ of Eiffel, it's essentially the 
ultimate multiple-inheritance object-oriented language. The designers 
took all the ideas of OO to their logical extreme, resulting in a very 
rigorous but quite complicated language. It does things like allow 
subclasses to rename inherited methods, but anyone calling through the 
superclass interface still gets the old names. Because when you have 
multiple superclasses, you might inherit two methods with clashing 
names, and you need to sort that out. Add generics, and it gets 
complicated fast.

C# doesn't allow MI, but it does attempt to stop changes to a superclass 
breaking all its subclasses. The idea being that company X changes their 
superclass to add a new method, who's name now clashes with a method 
defined in a subclass written by company Y. And the runtime supposedly 
sorts out all the same-name madness for you.

Arguably the only /good/ thing to come out of all of this is that if you 
/meant/ to override an inherited method, you have to explicitly /say/ so.

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.

It's true that having non-virtual methods introduces a tiny performance 
benefit. It's true that inheritance is over-used anyway, and you can 
usually get the same effect or better using collaboration instead. But 
still, the objection stands.

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.

Not only can you declare the accessibility of a thing, but there are 
restrictions on what you can do. A subclass can't make stuff more secret 
than its superclass (because clients might be using that interface 
instead). You can't make something public if it refers to private types. 
And so on.

As I sit here and listen to all these complicated rules about what can 
and can't be public and the convoluted rules for resolving a method call 
to an actual block of code, I can't help thinking... Did you guys ever 
thing that maybe if it ends up being this complicated, you're doing it 
wrong?

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

Still, not liking C# isn't going to change the fact that it is 
(apparently) the most popular programming language now... :-P

Post a reply to this message

On 13/08/2012 12:56 PM, Invisible wrote:
> Still, not liking C# isn't going to change the fact that it is
> (apparently) the most popular programming language now... :-P

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

Post a reply to this message

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. In other words, 
someone expecting the superclass's behavior to apply to a variable of the 
superclass's type won't see unexpected behavior without being warned.

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

You *can* do this.

class A {
    public x() { yadda1(); }
}

class B : A {
    new public x() { yadda2(); }
}

Now B is just like A, except x() calls a different yadda.

The only trick is that if you declare a variable of type A and invoke x() on 
it, you get A's x(), not B's. Unless A declares x() to be virtual, so 
callers of A.x() know they might be getting something different.

> It's true that having non-virtual methods introduces a tiny performance
> benefit. It's true that inheritance is over-used anyway, and you can usually
> get the same effect or better using collaboration instead. But still, the
> objection stands.

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. It's because 
of what I said above, which is that A.x() will call A.x()'s code unless A 
says otherwise.

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

> Not only can you declare the accessibility of a thing, but there are
> restrictions on what you can do. A subclass can't make stuff more secret
> than its superclass (because clients might be using that interface instead).
> 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?

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

> As I sit here and listen to all these complicated rules about what can and
> can't be public and the convoluted rules for resolving a method call to an
> actual block of code, I can't help thinking... Did you guys ever thing that
> maybe if it ends up being this complicated, you're doing it wrong?

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.

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

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. If 
you study the resolution rules as if they're math, instead of asking "why 
did the designers decide *this* would override *that*", then it's going to 
be confusing. Just like the visibility rules are complex if you don't think 
"well, what would it mean if I broke those rules? What would it do?"

> Still, not liking C# isn't going to change the fact that it is (apparently)
> the most popular programming language now... :-P

It's an excellent language in its class.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/13/2012 5:08, Invisible wrote:
> On 13/08/2012 12:56 PM, Invisible wrote:
>> Still, not liking C# isn't going to change the fact that it is
>> (apparently) the most popular programming language now... :-P
>
> 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.

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.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

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

Le 13/08/2012 22:22, clipka nous fit lire :
> 
> 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.

When all you have is a hammer, everything is a nail.

When you make the conception, once you know there can be only one true
linear hierarchy of classes and interfaces on the side, you integrate it
in your problem. You might even forbid yourself of thinking about
multiple inheritances.

Post a reply to this message

On 13-8-2012 23:00, Le_Forgeron wrote:
> Le 13/08/2012 22:22, clipka nous fit lire :
>>
>> 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.
>
> When all you have is a hammer, everything is a nail.

or a plank. You need planks too.
or a thumb. Hammers are great to remind one of thumbs.


-- 
Women are the canaries of science. When they are underrepresented
it is a strong indication that non-scientific factors play a role
and the concentration of incorruptible scientists is also too low

Post a reply to this message

On 8/13/2012 9:23, Orchid Win7 v1 wrote:
> And yet, not on any official Microsoft site. Weird, eh? (Especially whe
n you
> consider the extensive Java tutorials available from Sun.)

There are plenty of microsoft books on C#. Most of them are pretty good.

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

Well, read the free one, then!

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/13/2012 9:31, Orchid Win7 v1 wrote:
> I know that's what C++ does. But I got the impression that in C# this is a
> compile-time error.

No. You just need to say "new" like I showed in the example. It's probably 
an error or warning or something if you're recompiling a subclass, 
overriding a superclass method that already exists, and you don't say "new".

 > (Not that I can find any definitive word on this, mind
> you...)

I'm pretty sure it would be in the spec.

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

Sure. When you load the subclass, it just re-JITs the superclass.

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

I'm not sure why you'd find it confusing if you understand "internal" and 
"protected."

Basically, subclasses or anything compiled at the same time as this class.

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

No it doesn't. It probably lets you return an opaque reference to something 
you can't see the type of, but I doubt it lets you return a type that you 
can't see.

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

No it isn't difficult. It's right in the spec. Sure, there's a lot of steps 
to making the decision, but it's not difficult to codify.

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

Well, actually, everything's an object.

> I especially love how enumerations are a different type but no, not really,
> because obviously they're actually just integers...

No they aren't. Especially not the way Haskell defined "type". :-)

> 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 a little complex, but it really isn't difficult. Why would you care 
that bool isn't an enumeration?

>> It's an excellent language in its class.
>
> I SEE WHAT YOU DID THERE.

It's an excellent OO language that expects to have runtime and OS support 
around. It's a pretty crappy safety-critical realtime functional language.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/13/2012 7:53, Warp wrote:
> If diamond inheritance is the problem, then forbid diamond inheritance.

It turns out that having everything descend from Object (and other tricks 
like that) turn out to be more useful than multiple inheritance.

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

It doesn't matter there, because the problem with diamond inheritance is 
differing implementations and member variables, not the actual methods.

Eiffel did a nice job, but even there they never (AFAIK) actually 
implemented the spec.

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

Yep. Unless you explicitly use an unsafe construct.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 8/13/2012 9:22, Orchid Win7 v1 wrote:
> Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus
> defeating the whole point of the exercise.

Diamond inheritance isn't a problem if you don't have implementations.

OK, so Thread declares void run(), and DistressedDamsel declares void run(). 
Why would those declarations conflict?

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

It's becuase C# is a component-oriented language. It's designed to let 
people write code and release the object code and have others use it without 
recompiling.

It's also not intrinsically inefficient. For example, Singularity uses it to 
write its kernels in.

> Arguably you could have the compiler detect where dynamic binding is and is
> not needed. That requires whole-program analysis, however.

That's what Eiffel does.

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

Sure there is, because you recompile the code while it's running.

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

I kind of like where Go went: static duck typing.


-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

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

Yeah, that's what I thought.

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

If by "pretty smart" you mean "how /every/ programming language should 
work in the first place", then yes.

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

My point being that everybody acts like "oh, of /course/ you can't 
possibly do that", when in fact you can.

Besides, why should I avoid comparing things to Haskell? It's true that 
almost nobody has heard of it. But does that mean that it's OK for 
mainstream languages to be poor quality? I think not...

Post a reply to this message

On 13/08/2012 07:44 PM, Le_Forgeron wrote:
> 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...

Actually, I've never seen Windows 2000 used anywhere, ever. Not in 
people's homes, not in places of work. Indeed, if it weren't for that 
course my employer sent me on, I wouldn't even know it /exists/... It 
never seemed to be really popular.

> At least itanium is dead (or might... Oracle has been ordered to
> continue software support, for HP...), so Windows on itanium is dead.

It's a shame, really. AMD64 has /way/ too much old backwards 
compatibility cruft in it. In fact, the same could be said for the 
entire IBM PC-compatible platform. (Flip address line 20 to enable 
protected-mode? WTF is *that* about??)

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

Well, if all you need the OS to do is run your EPOS system, you probably 
don't give a **** about Aero, video authoring, DirectX 11, PC sync, or 
the bazillion and one new features in those newer OSes.

I still see commercial systems running MS-DOS, FFS! o_O

Post a reply to this message

On 14/08/2012 02:01 AM, Darren New wrote:
> On 8/13/2012 9:31, Orchid Win7 v1 wrote:
>> I know that's what C++ does. But I got the impression that in C# this
>> is a compile-time error.
>
> No. You just need to say "new" like I showed in the example. It's
> probably an error or warning or something if you're recompiling a
> subclass, overriding a superclass method that already exists, and you
> don't say "new".

So what happens if you say "override" on a method that isn't virtual?

>> (Not that I can find any definitive word on this, mind
>> you...)
>
> I'm pretty sure it would be in the spec.

Heh. And I thought Haskell was the only language stupid enough to claim 
that the reading the formal language specification is a good way to 
learn how to program with it...

>> Does that actually work? Given that you can load arbitrary new
>> subclasses at
>> any moment?
>
> Sure. When you load the subclass, it just re-JITs the superclass.

It actually does that?

>> 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.
>
> I'm not sure why you'd find it confusing if you understand "internal"
> and "protected."
>
> Basically, subclasses or anything compiled at the same time as this class.

I guess it makes sense once you realise it means OR, not AND.

>>> 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.
>
> No it doesn't.

O RLY?

> It probably lets you return an opaque reference to
> something you can't see the type of, but I doubt it lets you return a
> type that you can't see.

   module Foobar (Foo (..), foobar) where

   data Foo = Foo Int deriving Show
   data Bar = Bar Int deriving Show

   foobar :: Foo -> Bar
   foobar (Foo x) = Bar x

Notice how Bar is not exported, yet foobar is exported, and its return 
type is Bar.

Remember, Haskell functions deal with known types ALL THE TIME. Any time 
you call id :: x -> x, it takes a value of unknown type, and returns it 
unchanged. So for Haskell, having some data of a type that you can't 
"see" is no big deal at all. (With the minor detail that you now can't 
declare anything as returning Bar as its result, because that name is 
not in scope.)

More usually, of course, you would export the /name/, but not its 
/definition/. But you /can/ decide to not export the type at all, and 
still return it as a result, or take it as an argument.

>> 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.
>
> Well, actually, everything's an object.

Except that no, no it isn't. Apparently only values of reference types 
are considered "objects". :-P

You could /almost/ say "everything's a class", except that no, we have 
enums and stuff which aren't considered "classes".

What you /can/ say is that at least these 5 different things all behave 
rather more consistently than they do in Java...

>> I especially love how enumerations are a different type but no, not
>> really, because obviously they're actually just integers...
>
> No they aren't. Especially not the way Haskell defined "type". :-)

Right. So enumerations aren't integers, and that's why you define the 
corresponding integer value of each case right there in the definition? :-P

>> 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 a little complex, but it really isn't difficult. Why would you care
> that bool isn't an enumeration?

If you have real enumerations, why do you need a special-case for bool? 
To be, that just suggests that enumerations don't work properly.

(The same argument applies to Haskell: Why the HELL did they 
special-case the list type, when you can trivially define it manually? 
What there they thinking??)

> It's an excellent OO language that expects to have runtime and OS
> support around. It's a pretty crappy safety-critical realtime functional
> language.

OK, whatever. I haven't really explored it all that much yet, but it 
doesn't appear to compare well to Eiffel.

Post a reply to this message

On 14/08/2012 02:01 AM, Darren New wrote:
> It's an excellent OO language that expects to have runtime and OS
> support around.

...and yet, they claim it can be used for embedded systems, which don't 
even /have/ an OS?

Post a reply to this message

On 14/08/2012 02:03 AM, Darren New wrote:

> Eiffel did a nice job, but even there they never (AFAIK) actually
> implemented the spec.

FWIW, I thought they did. I don't have proof, however...

Post a reply to this message

On 14/08/2012 02:08 AM, Darren New wrote:
> On 8/13/2012 9:22, Orchid Win7 v1 wrote:
>> Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus
>> defeating the whole point of the exercise.
>
> Diamond inheritance isn't a problem if you don't have implementations.
>
> OK, so Thread declares void run(), and DistressedDamsel declares void
> run(). Why would those declarations conflict?

So if a class tries to implement both interfaces, it can't provide 
different implementations for these two distinct methods merely because 
their names clash?

>> 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.
>
> It's becuase C# is a component-oriented language. It's designed to let
> people write code and release the object code and have others use it
> without recompiling.
>
> It's also not intrinsically inefficient. For example, Singularity uses
> it to write its kernels in.

According to the Great Language Shootout, C# Mono is 3x slower than C. 
(Then again, Haskell is 2x slower...)

>> Arguably you could have the compiler detect where dynamic binding is
>> and is
>> not needed. That requires whole-program analysis, however.
>
> That's what Eiffel does.

Sure. Because Eiffel doesn't support dynamic linking.

>> 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.
>
> Sure there is, because you recompile the code while it's running.

That sounds remarkably hard to get right...

Post a reply to this message

Am 14.08.2012 10:06, schrieb Invisible:

>> C# has a lot of these "if you DO mean it, say so in the code" things.
>> Which I, personally, think is pretty smart.
>
> If by "pretty smart" you mean "how /every/ programming language should
> work in the first place", then yes.

So, how many (mainstream) programming languages have you seen that 
actually /do/ work this way?

C# is pretty "innovative" in that respect.


>>>> 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.
>
> My point being that everybody acts like "oh, of /course/ you can't
> possibly do that", when in fact you can.

You can't with the conceptual approach used by C#. You know, the "I can 
verify at compile time that the object referenced by variable X can do 
A, B, C and D."

If you want to give such guarantees, you can't handle variables of types 
for which you have no declaration, because obviously you can't tell 
whether they can do A, B, C and D or not.


> Besides, why should I avoid comparing things to Haskell? It's true that
> almost nobody has heard of it. But does that mean that it's OK for
> mainstream languages to be poor quality? I think not...

Andy, be fair. The fact that there's /someting/ programming language X 
can't do that Haskell can doesn't mean that programming language X is 
"poor quality".

I'd dare say C# is actually pretty /high/ quality (at least the language 
per se; one might argue about its standard libraries); there's something 
to the claim that it's kind of "Java done right".

Post a reply to this message

On 14/08/2012 11:17 AM, clipka wrote:

> So, how many (mainstream) programming languages have you seen that
> actually /do/ work this way?
>
> C# is pretty "innovative" in that respect.

If doing things right rather than copying the old kludges that everybody 
else uses is "innovative", then sure...

>> My point being that everybody acts like "oh, of /course/ you can't
>> possibly do that", when in fact you can.
>
> You can't with the conceptual approach used by C#. You know, the "I can
> verify at compile time that the object referenced by variable X can do
> A, B, C and D."
>
> If you want to give such guarantees, you can't handle variables of types
> for which you have no declaration, because obviously you can't tell
> whether they can do A, B, C and D or not.

...and yet, in my Haskell snippet, a type is not exported, yet still you 
can convert it to a string, because that interface is implemented.

Obviously /the compiler/ must be able to see the declaration for the 
type. But that doesn't mean that /the programmer/ needs to.

> Andy, be fair. The fact that there's /someting/ programming language X
> can't do that Haskell can doesn't mean that programming language X is
> "poor quality".

No, that's true. I was really point pointing out that somebody says "X 
*must* work this way", and, er, no, it doesn't. It could work 
differently if you wanted it to. I guess it's a silly thing to argue 
about though.

My real concerns about C# are that they seem to have added a feature for 
everything, rather than step back and look for a simpler, more elegant 
design that solves everything, not just the things they added specific 
features for.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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?

Given that interfaces cannot contain member variables nor function
implementations (at least not in any language I know of), it would make
the GUI library *really* annoying to use because of all the required code
repetition. (For example, every time the library needs to know the
coordinates of the object on screen, it would have to call a function
declared in the interface, which the user would have to implement in his
own code to return those coordinates. It would also cripple any possibility
of using eg. a screen element that contains other screen elements, because
such an object would just be an interface and cannot contain anything.)

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

Inheritance implements the OO concept of an "is-a" relationship. If a class
implements an interface, then it effectively has an "is-a" relationship to
it. (For example, if the interface is named, let's say, ButtonListener,
and you implement it, then your class "is-a" ButtonListener. You can give
an object of your class to anything that expects a ButtonListener. It doesn't
get any more straightforward and clear inheritance than that.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> >> 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.

In a single inheritance case the compiler simply internally builds a
data structure with all the data members of the entire inheritance
hierarchy one after another. The base class portion of the structure
looks identical to the one that would exist if you instantiated the
base class directly (and hence any function that deals with the base
class members can deal directly with the inherited class object).

If the class contains any virtual functions, then a virtual table pointer
will be added to the data structure (typically, though not necessarily,
at the beginning of it).

(If the base class did not contain any virtual functions but the derived
function does, it's perfectly possible for the 'this' pointer to change
in value when a base class method is called, in order to point to the
base class part of the structure. The base class member function will be
none the wiser, and work just right.)

In a (non-diamond) multiple inheritance case the same thing is done,
basically. The data of the base classes is just put one after the other
in the derived class' data structure (and the 'this' pointer is changed
as necessary when calling the base class member functions).

In a diamond inheritance situation you have a choice to make: Do you want
each of the multiple parents to be "independent" of each other (which
means that the data from the common parent class is kept separately),
or do you want them to share the data from the common parent class?

In the latter case the data from the common parent class is stored only
once in the most-derived class' data structure, and virtual table trickery
is used to make the in-between class methods to change the 'this' pointer
appropriately when calling the base class methods (or if the in-between
classes want to read/change the base class member variables directly).

(In the former case the in-between classes behave just like there was
no multiple inheritance at all, handling their own "local copy" of the
common base class.)

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

But if your class were eg. the size of one pointer, then adding any virtual
functions would double its size.

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Vista, 7, 8... who cares, XP runs!

Not a good gaming platform anymore. (Microsoft wants XP to die, so they
refuse to update DirectX for it.)

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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.

Only if you don't mind the need for code repetition with interfaces.

-- 
                                                          - Warp

Post a reply to this message

Am 14.08.2012 10:31, schrieb Invisible:
> On 14/08/2012 02:01 AM, Darren New wrote:
>> On 8/13/2012 9:31, Orchid Win7 v1 wrote:
>>> I know that's what C++ does. But I got the impression that in C# this
>>> is a compile-time error.
>>
>> No. You just need to say "new" like I showed in the example. It's
>> probably an error or warning or something if you're recompiling a
>> subclass, overriding a superclass method that already exists, and you
>> don't say "new".
>
> So what happens if you say "override" on a method that isn't virtual?

Haven't done much C# programming lately, so currently I'm not that firm 
on the various keywords, but if "override" is that keyword used to do 
virtual method override and "new" is that keyword used to do static 
method override, then you'd surely get a compile-time error, because 
what you tell the compiler about your derived class doesn't fit what the 
compiler knows about the parent class.

Makes a lot of sense, because trying to perform virtual method override 
on a non-virtual method is a strong indicator that you don't know what 
you're doing.


You need to get used to all those keywords, that's all.


>> It probably lets you return an opaque reference to
>> something you can't see the type of, but I doubt it lets you return a
>> type that you can't see.
>
>    module Foobar (Foo (..), foobar) where
>
>    data Foo = Foo Int deriving Show
>    data Bar = Bar Int deriving Show
>
>    foobar :: Foo -> Bar
>    foobar (Foo x) = Bar x
>
> Notice how Bar is not exported, yet foobar is exported, and its return
> type is Bar.

You've proven us wrong: We named a wrong reason for why the following 
construct doesn't make any sense:

     class Foobar
     {
         private class Bar;    // (1)
         public Bar foobar();  // (2)
     }

Read this carefully, trying to understand it not just syntactically but 
also what it means in the OO concept:

In (1), the "class Bar" tells us (and the compiler) that there is a 
class named "Foobar::Bar", and the "private" keyword tells us (and the 
compiler) that the mere /existance/ of this type is part of Foobar's 
"hidden" implementation details, not to exposed to anything else.

In (2), the "Bar foobar()" tells us (and the compiler) that every Foobar 
object provides an operation named "Foobar::foobar()" returning a value 
of type "Bar", with the "public" keyword telling us (and the compiler) 
that the operation is part of the official interface of the class, to be 
exposed to the whole world.

Notice how (2) implies that the mere /existence/ of a class named 
"Foobar::Bar" must also be part of the official interface. If the 
implementation of Foobar is ever changed, the class "Foobar::Bar" must 
still be retained in order to not break existing code using the class. 
But in (1) we already specified that even the existence of the 
"Foobar::Bar" class is just an implementation detail.


Of course it's perfectly possible to expose the existence of an inner 
class without exposing its details. You just need to use the proper 
keyword on the members of the inner class. (Not sure off the top of my 
hat which one that is.)


> More usually, of course, you would export the /name/, but not its
> /definition/. But you /can/ decide to not export the type at all, and
> still return it as a result, or take it as an argument.

That's quite a stupid thing to do, because you then can't tell at 
compile-time whether some other function expecting a parameter of type 
"Bar" actually gets passed such a type when using (in C++ style pseudocode):

     Foobar f;
     ANY_TYPE x;

     x = f.foobar();
     ...
     f.barfoo(x);

>>> 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 a little complex, but it really isn't difficult. Why would you care
>> that bool isn't an enumeration?
>
> If you have real enumerations, why do you need a special-case for bool?
> To be, that just suggests that enumerations don't work properly.

In C#, it might have something to do that enums are far more powerful 
than in other languages, possibly creating some overhead; you really 
want to avoid that for the ubiquitous bool type. (Matter of fact, C# 
enums are more like syntactical sugar for classes employing the Atom 
design pattern, rather than a collection of integer constants.)


>> It's an excellent OO language that expects to have runtime and OS
>> support around. It's a pretty crappy safety-critical realtime functional
>> language.
>
> OK, whatever. I haven't really explored it all that much yet, but it
> doesn't appear to compare well to Eiffel.

I don't know Eiffel, but I'd be surprised if Eiffel could compete with 
C# in what C# was designed for: Being a mainstream language for 
mainstream PC desktop applications, running on a VM and providing decent 
performance.

Of course, if you expect C# to be fit for stuff way outside this 
ballpark, it's no surprise you'll be disappointed.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 8/13/2012 7:53, Warp wrote:
> > If diamond inheritance is the problem, then forbid diamond inheritance.

> It turns out that having everything descend from Object (and other tricks 
> like that) turn out to be more useful than multiple inheritance.

Does Object contain member variables? If not, then I don't see the problem.

Even if it does, then the language could implicitly do with it what C++'s
virtual inheritance does. You can still forbid all other types of diamond
inheritance if you so wish.

-- 
                                                          - Warp

Post a reply to this message

Am 14.08.2012 10:32, schrieb Invisible:
> On 14/08/2012 02:01 AM, Darren New wrote:
>> It's an excellent OO language that expects to have runtime and OS
>> support around.
>
> ...and yet, they claim it can be used for embedded systems, which don't
> even /have/ an OS?

You'd be surprised how many embedded systems /do/ have an OS.

Post a reply to this message

On 14/08/2012 12:13 PM, Warp wrote:
> Le_Forgeron<jgr### [at] freefr>  wrote:
>> Vista, 7, 8... who cares, XP runs!
>
> Not a good gaming platform anymore. (Microsoft wants XP to die, so they
> refuse to update DirectX for it.)

Valid point. But in a commercial setting, pretty irrelevant.

(Unless you happen to be a games developer, I suppose...)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 14/08/2012 12:13 PM, Warp wrote:
> > Le_Forgeron<jgr### [at] freefr>  wrote:
> >> Vista, 7, 8... who cares, XP runs!
> >
> > Not a good gaming platform anymore. (Microsoft wants XP to die, so they
> > refuse to update DirectX for it.)

> Valid point. But in a commercial setting, pretty irrelevant.

It will become relevant when Microsoft inevitably stops supporting XP.

It might not happen next month, or even next year, but the clock is
ticking.

-- 
                                                          - Warp

Post a reply to this message

Am 14.08.2012 12:46, schrieb Invisible:
> On 14/08/2012 11:17 AM, clipka wrote:
>
>> So, how many (mainstream) programming languages have you seen that
>> actually /do/ work this way?
>>
>> C# is pretty "innovative" in that respect.
>
> If doing things right rather than copying the old kludges that everybody
> else uses is "innovative", then sure...

That's exactly my ppint.

> My real concerns about C# are that they seem to have added a feature for
> everything, rather than step back and look for a simpler, more elegant
> design that solves everything, not just the things they added specific
> features for.

C# was never meant to win a design contest. It was meant to be a decent 
everyday programming language.

Besides, there's no such thing as as an elegant design that solves 
everything [with reasonable effort for the language user]. Many tasks 
require certain common design patterns you don't want to re-implement 
over and over again, so one way or another you'd end up adding layers on 
top of that elegant design, which - because the elegant design doesn't 
provide them out of the box - will often be far from elegant to use.

Post a reply to this message

Am 14.08.2012 13:00, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> 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?
>
> Given that interfaces cannot contain member variables nor function
> implementations (at least not in any language I know of), it would make
> the GUI library *really* annoying to use because of all the required code
> repetition. (For example, every time the library needs to know the
> coordinates of the object on screen, it would have to call a function
> declared in the interface, which the user would have to implement in his
> own code to return those coordinates.

I guess you've heard of code re-use through delegation, no?


> It would also cripple any possibility
> of using eg. a screen element that contains other screen elements, because
> such an object would just be an interface and cannot contain anything.)

I have no idea what you're saying there. If you're saying what I'm 
reading, it's plain nonsense.


>> 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".
>
> Inheritance implements the OO concept of an "is-a" relationship. If a class
> implements an interface, then it effectively has an "is-a" relationship to
> it. (For example, if the interface is named, let's say, ButtonListener,
> and you implement it, then your class "is-a" ButtonListener. You can give
> an object of your class to anything that expects a ButtonListener. It doesn't
> get any more straightforward and clear inheritance than that.)

In common parlance, "inheritance" means "multi-level inheritance" though 
(and in the OP quoted above it was obviously meant that way), and a 
single tier of interfaces and a single tier of implementing classes 
doesn't really cut it.


I do agree that at least inheritance among interfaces would be nice to 
have, but it's not entirely impossible to implement a GUI library even 
without that.

Post a reply to this message

>> Valid point. But in a commercial setting, pretty irrelevant.
>
> It will become relevant when Microsoft inevitably stops supporting XP.
>
> It might not happen next month, or even next year, but the clock is
> ticking.

What do you mean "when"? This has already happened.

http://en.wikipedia.org/wiki/Windows_XP

"Mainstream support ended 14 April 2009."

Post a reply to this message

Am 13.08.2012 23:00, schrieb Le_Forgeron:
> Le 13/08/2012 22:22, clipka nous fit lire :
>>
>> 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.
>
> When all you have is a hammer, everything is a nail.
>
> When you make the conception, once you know there can be only one true
> linear hierarchy of classes and interfaces on the side, you integrate it
> in your problem. You might even forbid yourself of thinking about
> multiple inheritances.

As I said, it's "current widespread belief"; I won't dare to make any 
claims about its boolean value, but on the basis of this belief, the 
decision to restrict multiple inheritance to interfaces is perfectly 
logical.

Post a reply to this message

On 14/08/2012 12:33 PM, clipka wrote:
> C# was never meant to win a design contest. It was meant to be a decent
> everyday programming language.

And surely starting with a solid design is the best way to do that.

> Besides, there's no such thing as as an elegant design that solves
> everything [with reasonable effort for the language user].

I disagree.

> Many tasks
> require certain common design patterns you don't want to re-implement
> over and over again, so one way or another you'd end up adding layers on
> top of that elegant design, which - because the elegant design doesn't
> provide them out of the box - will often be far from elegant to use.

Again, I do not agree.

Post a reply to this message

Am 14.08.2012 00:17, schrieb andrel:

>> When all you have is a hammer, everything is a nail.
>
> or a plank. You need planks too.
> or a thumb. Hammers are great to remind one of thumbs.

LOL!

Post a reply to this message

On 13/08/2012 11:17 PM, andrel wrote:
> or a thumb. Hammers are great to remind one of thumbs.

My thumb almost hurts now...

Post a reply to this message

Am 14.08.2012 10:40, schrieb Invisible:

>> Diamond inheritance isn't a problem if you don't have implementations.
>>
>> OK, so Thread declares void run(), and DistressedDamsel declares void
>> run(). Why would those declarations conflict?
>
> So if a class tries to implement both interfaces, it can't provide
> different implementations for these two distinct methods merely because
> their names clash?

Depends on the language. You could, for instance, have a syntax to 
define a Thread::run() and a separate DistressedDamsel::run(); don't 
know whether C# can do that though. Maybe, maybe not. I'd just make a 
guess that Java can't do it.


> According to the Great Language Shootout, C# Mono is 3x slower than C.
> (Then again, Haskell is 2x slower...)

A factor of 3x compared to what is probably the fastest 
more-or-less-high level language doesn't sound that bad to me, given how 
much easier it is to program anything serious in it. (You don't want to 
write a GUI program in C, do you?! You'd at least want C++)


>> Sure there is, because you recompile the code while it's running.
>
> That sounds remarkably hard to get right...

Ever heard of JIT-compilers?

All you need to do is mark the corresponding classes as not-yet-compiled 
again.

Post a reply to this message

>>> OK, so Thread declares void run(), and DistressedDamsel declares void
>>> run(). Why would those declarations conflict?
>>
>> So if a class tries to implement both interfaces, it can't provide
>> different implementations for these two distinct methods merely because
>> their names clash?
>
> Depends on the language. You could, for instance, have a syntax to
> define a Thread::run() and a separate DistressedDamsel::run(); don't
> know whether C# can do that though. Maybe, maybe not. I'd just make a
> guess that Java can't do it.

Is there /anything/ Java does right? ;-)

>> According to the Great Language Shootout, C# Mono is 3x slower than C.
>> (Then again, Haskell is 2x slower...)
>
> A factor of 3x compared to what is probably the fastest
> more-or-less-high level language doesn't sound that bad to me, given how
> much easier it is to program anything serious in it. (You don't want to
> write a GUI program in C, do you?! You'd at least want C++)

My point is, adding a low-level feature to shave off 0.02% runtime 
overheard in a language which already has 200% overhead seems... odd.

Post a reply to this message

Am 14.08.2012 13:59, schrieb Invisible:
> On 14/08/2012 12:33 PM, clipka wrote:
>> C# was never meant to win a design contest. It was meant to be a decent
>> everyday programming language.
>
> And surely starting with a solid design is the best way to do that.

The C# design /is/ pretty solid for a modern language. Much more solid 
at least than the current Java language (which has added tons of kludgy 
stuff because they found their initial elegang solution wasn't that 
elegant after all for plenty of use cases), or the newest C++ 
incarnation (which has added badly needed stuff - like smart pointers, 
to name just one example - via templates, leading to a somewhat 
cumbersome syntax for everyday stuff).

The reason for C# being pretty solid is precisely that they did /not/ 
aim for an elegant core language to add the other features on top, but 
rather designed a language that provides all the features out of the 
box, with a somewhat consistent syntax and all.


>> Besides, there's no such thing as as an elegant design that solves
>> everything [with reasonable effort for the language user].
>
> I disagree.

You're free to do that. Still, do you happen to know any counterexample? 
(And if so, why aren't you using that language?)


>> Many tasks
>> require certain common design patterns you don't want to re-implement
>> over and over again, so one way or another you'd end up adding layers on
>> top of that elegant design, which - because the elegant design doesn't
>> provide them out of the box - will often be far from elegant to use.
>
> Again, I do not agree.

Again, a few counterexamples might give your disagreement a /bit/ more 
weight.


Oh, and don't bother to mention Haskell in this context; you've done a 
fair share of ranting about that language already to disqualify it for 
the position of "an elegant design that solves everything [without 
accumulating non-elegant layers of additional features]".

Post a reply to this message