Another C# critique

[christopher diggins]

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up
the following issues :

- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft

I am perhaps guilty somewhat of being a flame baiting troll, but at the same
time I honestly want to improve on the critique.

Thanks in advance for your responses.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com

[William Ryan]

1) Unsafe Code - Sometimes you need it, plain and simple. .NET is still
work in progress and there aren't managed wrappers for everything.
Developers don't have the luxury of deciding whether or not they use unsafe
code if the project demands something that necessitates it. Moreoever,
there's a good amount of legacy code that may well (and often is) in need of
using Unsafe
2) Attributes - Huh? Take for example FileIOPermissio n attribute...you can
mark 10 different directories with only Read permissions thereby eliminating
the need for checking hardcoded values and ugly branch logic before reading
or writing a file. I could go on and on about this, but I think you are way
off base here. And you aren't forced to use them...I bet there are tons of
..NET developers that barely know they exist for God's sake.
3- Garbage Collection - Yes, all of the benefits you get from Managed code
aren't totally free.
4- Allows non-deterministic destructors - If you dispose of your objects
when you are done with them, I'm not sure what the problem is. What problem
is this causing you?
5- Type/Reference Types.... Dude, there's so few value types I could recite
them off the top of my head. That's hardly a chore and so simple most
college CS freshman would love to have that as a Question on a test
As far as Objects can't exist on the stack....that's part and parcel to your
other complaint
6-Boxing vs. UnBoxing Depends on the types...I agree that it's not the most
intuitive concept, but once again, it's hardly a concept that can't be
understood.
7-Mutability - Ok, but what does that stop you from doing? Couldn't you use
Attributes to set the objects value and not provide accessors to change it?
8-Class as Modules and Programs - <<A static class with only static data and
static methods should either be a module or a program.>> Why?
9-Polymorphism - Why can't you use multiple Interfaces?
10-Generics and Missing Templates.... ok, they didn't get everything up
front, but if you want to use it, use it, if not, don't. Would it be better
for them to not provide this functionality? What if you were just starting
C# programming with the advent of 2.0 and didn't have legacy code? Wouldn't
you want generics?
11- Source File Layout - Can't you get all of that information via
reflection or using the CodeModel?
12 - Public Fields---Not if you don't do it. Is it really Microsoft's
responsibilty to ensure that every programmer doesn't violate the rules of
OOP? Besides, if they tried stopping this, there'd be so many VB
Programmers screaming bloody murder it wouldn't be funny. And while I
believe that you shouldn't break encapsulation, there are lots of people
that have...or have inherited code from people that did and prohibiting it
would impede adoption. Say what you want about MS, they bend over backwards
to support legacy code.
Special Primitives - Once again, so what?
13- Is it a field..
If it were a function, you'd see the () around it. Go ahead and try, if you
don't put the parens around it, it won't compile. As testimony to this, go
see how many VB Programmers constantly complain about forgetting the parens
when they call ToString without the Parens.

And finally, other than the issue of unsafe code which VB.NET doesn't
support, aren't all of these related to the CLR and the Framework rather
than C#?
"christophe r diggins" <cd******@video tron.ca> wrote in message
news:V7******** ************@we ber.videotron.n et...

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up the following issues :

- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft

I am perhaps guilty somewhat of being a flame baiting troll, but at the same time I honestly want to improve on the critique.

Thanks in advance for your responses.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com

[babylon]

I think C#/.Net is great, except that there is no mature Virtual Machine /
Class Library for non-windows platform.
mono is not a good solution...
what I want is a truely java-like write once run everywhere

"christophe r diggins" <cd******@video tron.ca> wrote in message
news:V7******** ************@we ber.videotron.n et...

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up the following issues :

- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft

I am perhaps guilty somewhat of being a flame baiting troll, but at the same time I honestly want to improve on the critique.

Thanks in advance for your responses.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com

[Sami Vaaraniemi]

While some of your comments about C# do have a point, most of the time the
case is that you can work around the issues in one way or another.

However, I could not disagree more with what you say about attributes.
Attributes allow you to move out code that is not essential to the logic of
your function. E.g.,

// non-attributes version
public void DoASensitiveThi ng()
{
if (!LookUpUserAut henticationInfo AndCheckHeHasPr operRoles())
throw new AccessDeniedExc eption();
// do the actual logic here
}

// attributes version
[RolesRequired(" Admin")]
public void DoASensitiveThi ng()
{
// do the actual logic here
}

The code is more readable in the version that uses attributes because things
that are not really part of the business logic have been moved out of the
code. It makes it easier for the reader to see what is happening because the
business logic is not cluttered with extra code.

I do not understand your comparison of attributes with C++ macros. C++
macros are somewhat evil in that they can lead to very obscure and hard to
find bugs due to the fact that they are preprocessed, not compiled. The way
macro arguments are evaluated can cause nasty problems due to side-effects,
double-evaluation and operator precedence. Attributes do not suffer from any
of these problems.

Regards,
Sami

[Jon Skeet [C# MVP]]

christopher diggins <cd******@video tron.ca> wrote:

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up
the following issues :

- unsafe code
If you don't like it, don't use it. I never have.
- attributes
Couldn't disagree more - attributes are lovely, when used
appropriately. I rarely need to use them. but when I do they're very
handy.
- garbage collection
Yes, you're effectively forced to use garbage collection. I don't see
that as a bad thing.
- non-deterministic destructors
So don't rely on destructors being deterministic. Don't assume the RAII
idiom of C++ works in C# - it doesn't. Use the IDisposable idiom
instead.
- Objects can't exist on the stack
Using reference types for almost everything simplifies things
enormously, I find. Then again, I come from a Java background.
- Type / Reference Types
No, a type itself doesn't decide whether it'll be on the stack or the
heap - not directly, anyway. Reference types will always be on the
heap, but value types will be wherever the variable is declared - only
local variables and variables within other objects on the stack will be
on the stack. Again, I just don't see why this is a problem.
- Boxing / Unboxing
Your example is flawed - boxing will only occur in the case where
"anothertyp e" is object. Otherwise there has to be a user-defined
implicit conversion occurring, which is much more dangerous, IMO.

Boxing can indeed be confusing, but I believe that it's a necessary
evil to some extent.
- Mutability
Objects can certainly be immutable - take string, for instance. You
can't, however, declare a variable or method to be "const" - is that
what you're really after?
- Classes as Modules and Programs
The System namespace most certainly *shouldn't* export a method called
WriteLine. WriteLine is acting on a console, so rightly belongs in a
console class. I don't see anything wrong with a type itself having
data.
- Polymorphism through Class Inheritance
- Interface Delegation
Both of these (which are basically one complaint, as far as I can see)
are reasonably valid.
- Interface Extensions
Yes, that could be nice.
- C# Missing Template Template Parameters
I don't know enough about generics to comment, but yes, that's
possible. Of course, Whidbey hasn't actually shipped yet, so things can
still change.
- Late Added Generics
I think there are far better examples here - namely the many collection
classes which would have been unnecessary had generics been there at
the start.
- Source File Layout
Not sure what you mean by "Heron code", but I agree that usually one
class per file is the best option.
- Public Fields
It doesn't violate "the principle of objects" in my view but it's
certainly a bad idea. It's not like C# forces you to do this though,
and if you're worried about it
- Special Primitives
In what way does it reduce the flexibility of the language? What is the
alternative?
- Is it a Property or is it a field?
Assuming you're using classes which follow the conventions, it's always
clear what you're doing. I would be reticent to use a library which
didn't follow the naming conventions anyway.
- Microsoft
I don't see how you can really compare what MS did with Java to what it
can do with C#. C# can already be used in a practical sense outside
Windows. Even if it could only be used on Windows, however, that
wouldn't make it a useless language by any means.
I am perhaps guilty somewhat of being a flame baiting troll, but at the same
time I honestly want to improve on the critique.

It strikes me that absolutely none of these is a convincing reason not
to use C#. A few are interesting ideas for future development, but many
just don't seem to be an issue to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jax]

I'm not at all an expert on the whole comparison thing between different languages, despite that even I can notice that your trying too hard to criticize C#
What language are you offering as the alternitive? And what problems does that one have?

> - unsafe code

I think that if you would not allow mixed managed/unmanaged code, then no
one is going to jump on .NET since too much tested code exists and it will
take years to port to .NET code. The transition process is slo, but the
programs wil become more and more stable.

I think that the User interfaces will become more and more pure .NET,the but
the none-user interface functionality will be ported in time.
- Objects can't exist on the stack

Objects on the stack are an open door to the dreaded buffer overflows.
I think that this is a very good step forward towards stability of the
software.

[Miha Markic]

Others already commented other points.

- Public Fields

For very simple fields: the code is reduced and you can always extend them
to private field/public property.

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com
www.rthand.com

[Philip Rieck]

In addition to responses already given:

You seem to be championing "Heron" instead of c#, based on the page you
linked to. However, the available "spec" for Heron is so bare as to be
un-critiqueable ( for example you mention calling destructors, but not
defining them)

However, there are some huge real-world problems already: - here's a very
partial list from a quick perusal
-it mentions specifically that there will be no support for concurrency.
So this language can only be used for small tools and hobby applications?

- No namespaces : what do you do for name clashes if you are importing
multiple libraries? Real example: I am using a third party library that has
bugs. They release a new version, but it has twelve new public classes that
have the same name as that in another third-party library I have. What now?
There's very good reasons why modern languages support namespaces, but Heron
does not seem to address these at all.

- No RTTI: if I were passed a "variant array" of different objects, how
would I verify (or utilize) that they all implement a specific interface?
would the "please pass me IDoThisable" constraint be just a documented? What
if my method can use either IDoThisable or IDoThatable -- there would be no
way for me to choose other try-ing it and catching casting exceptions.

- No "Protected" : due to the nature of the inheritance method you are using,
there is no (and possibly can never be) concept of protected access. So
when designing a type I must either decide to break encapsulation and expose
implementation details to the world, or make it extremely difficult (or
impossible) for derived classes to alter that implementation.
And many, many questions (that you may have considered but not answered in
the specs) - some of them:
- How would I call into a library written in a language other than Heron?
- Memory uses reference counting: what is done about circular references?
- If I am extending two interfaces that have type conversion operators to
"int" delegated to two separate classes, which is called? Or do I need to
produce type conversion for any class I create regardless of interfaces
delegated (sounds like repeating lots of work)?
- Streams are used but only have one method of access : the "|>" operator.
How about rewinding? Peeking? Application-defined buffering? And I guess I
don't have to ask about asynchronous reads from slow media, as no
concurrency is allowed.
It seems like a half-baked language. C# is designed and evolving to allow
for real-world usage by the masses - it has constraints imposed on it by the
environments that it must run under, so it does have some quirks. c# doesn't
omit multiple inheritance because the designers think it's useless -- it's
left out because it is such a huge effort to include that the time is deemed
better spent elsewhere.

Boxing and unboxing isn't included in c# as a "feature", it's there to solve
a problem introduced because of design decisions elsewhere (that is, it is
the consequence of a decision to keep the simplicity of "everything is an
object" and still perform acceptably). Yes, it can be difficult for some to
understand -- but removing it would cause larger and more undesirable
problems (in my opinion).
But keep critiquing c# : each time a person does ( if it's informed and
intelligent or not), c# gets another opportunity to either improve or be
better understood.


"christophe r diggins" <cd******@video tron.ca> wrote in message
news:V7******** ************@we ber.videotron.n et...

I have posted a C# critique at
http://www.heron-language.com/c-sharp-critique.html. To summarize I bring up the following issues :

- unsafe code
- attributes
- garbage collection
- non-deterministic destructors
- Objects can't exist on the stack
- Type / Reference Types
- Boxing / Unboxing
- Mutability
- Classes as Modules and Programs
- Polymorphism through Class Inheritance
- Interface Delegation
- Interface Extensions
- C# Missing Template Template Parameters
- Late Added Generics
- Source File Layout
- Public Fields
- Special Primitives
- Is it a Property or is it a field?
- Microsoft

I am perhaps guilty somewhat of being a flame baiting troll, but at the same time I honestly want to improve on the critique.

Thanks in advance for your responses.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com

[christopher diggins]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message up

the following issues :

- unsafe code
If you don't like it, don't use it. I never have.

When someone else uses it, then I have a problem. i.e. Other assemblies,
libraries, etc.

- attributes

Couldn't disagree more - attributes are lovely, when used
appropriately. I rarely need to use them. but when I do they're very
handy.

I have seen some really dastardly usage of the things by Microsoft hackers.
This is why I compared them to Macros, reminded me of the level of
obfuscation introduced into C++ by MFC. Nonetheless, I removed the macro
comparison, and I am desperately looking for that example I had seen in
order to back up my position.

- garbage collection

Yes, you're effectively forced to use garbage collection. I don't see
that as a bad thing.

Yes, I can see that for some people that is fine.

- non-deterministic destructors

So don't rely on destructors being deterministic. Don't assume the RAII
idiom of C++ works in C# - it doesn't. Use the IDisposable idiom
instead.

And assuming no one else does neither. Again, problems are not always of our
own creation.

- Objects can't exist on the stack

Using reference types for almost everything simplifies things
enormously, I find. Then again, I come from a Java background.

It does lead to the boxing/unboxing problem.

- Type / Reference Types

No, a type itself doesn't decide whether it'll be on the stack or the
heap - not directly, anyway. Reference types will always be on the
heap, but value types will be wherever the variable is declared - only
local variables and variables within other objects on the stack will be
on the stack. Again, I just don't see why this is a problem.

sometype x;

is that a pointer/reference to sometype, or is it a actually an initialized
instance of sometype. Depends on whether sometype is a struct or a class.
That is the problem. The single simple declaration statement is now horribly
unclear.

- Boxing / Unboxing

Your example is flawed - boxing will only occur in the case where
"anothertyp e" is object. Otherwise there has to be a user-defined
implicit conversion occurring, which is much more dangerous, IMO.

class Test
{
static void Main() {
sometype x;
anothertype y;
x = y; // boxed or unboxed???
y.ModifyState() ;
// Now what is the state of x?
}
}

Yes thanks for pointing out that my example is flawed. Interestingly enough
so is your explanation. It should be "boxing will only occur in the case
where "sometype" is object.
Boxing can indeed be confusing, but I believe that it's a necessary
evil to some extent.

If you want an object to always be a reference, then it is neccessary I
agree.

- Mutability

Objects can certainly be immutable - take string, for instance. You
can't, however, declare a variable or method to be "const" - is that
what you're really after?

Yes I want :

const myobject x;

In other words I want to be able to declare a immutable instance of
myobject. I changed the wording :

"C# does not allow immutable user defined objects."

Am I making sense now?

- Classes as Modules and Programs

The System namespace most certainly *shouldn't* export a method called
WriteLine. WriteLine is acting on a console, so rightly belongs in a
console class. I don't see anything wrong with a type itself having
data.

Why shouldn't another namespace export methods? It can be very practical to
define modules that do things without always requiring that the exact object
that provides it. I don't recommend modifying the system namespace, but I
would write a new namespace with long nasty old functions shortened to
somethign more usable.

Just because it isn't object oriented doesn't mean that it isn't a useful
technique.

As for types having their own data. This is a delicate stance that I have
very little support in the OO community for. Essentially my argument is that
the role of a class is to define the implementation, methods and data for
instances. Static data is something we have all gotten used to but is
information that would possibly be better suited for a namespace then in the
class IMHO.

- Polymorphism through Class Inheritance
- Interface Delegation

Both of these (which are basically one complaint, as far as I can see)
are reasonably valid.

- Interface Extensions

Yes, that could be nice.

- C# Missing Template Template Parameters

I don't know enough about generics to comment, but yes, that's
possible. Of course, Whidbey hasn't actually shipped yet, so things can
still change.

- Late Added Generics

I think there are far better examples here - namely the many collection
classes which would have been unnecessary had generics been there at
the start.

- Source File Layout

Not sure what you mean by "Heron code", but I agree that usually one
class per file is the best option.

- Public Fields

It doesn't violate "the principle of objects" in my view but it's
certainly a bad idea. It's not like C# forces you to do this though,
and if you're worried about it

- Special Primitives

In what way does it reduce the flexibility of the language? What is the
alternative?

- Is it a Property or is it a field?

Assuming you're using classes which follow the conventions, it's always
clear what you're doing. I would be reticent to use a library which
didn't follow the naming conventions anyway.

- Microsoft

I don't see how you can really compare what MS did with Java to what it
can do with C#. C# can already be used in a practical sense outside
Windows. Even if it could only be used on Windows, however, that
wouldn't make it a useless language by any means.

I am perhaps guilty somewhat of being a flame baiting troll, but at the same time I honestly want to improve on the critique.

It strikes me that absolutely none of these is a convincing reason not
to use C#. A few are interesting ideas for future development, but many
just don't seem to be an issue to me.

I agree that no single problem here is enough even for me to reject the
language. But definitely things add up when you start taking two or three.

Thanks for the insightful comments.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com