 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] dev null> 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
|
|
| |
| |
|
|
|
|
| |
|
|
