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.

 

[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 FileIOPermission 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#?

 

[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

 

[Jon Skeet [C# MVP]]

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

 

[Guest]

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?

 

[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 DoASensitiveThing()
{
if (!LookUpUserAuthenticationInfoAndCheckHeHasProperRoles())
throw new AccessDeniedException();
// do the actual logic here
}

// attributes version
[RolesRequired("Admin")]
public void DoASensitiveThing()
{
// 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

 

[Guest]

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

 

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

 

[christopher diggins]

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.

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.

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.

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.

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.

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.

Your example is flawed - boxing will only occur in the case where
"anothertype" 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.

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?

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.

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


Yes, that could be nice.


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.


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.


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


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


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


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.


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.


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.

 

[Brian W]

OK ladies and gentlemen, don't feed the troll.

This guy is just trying to gather support for his language (Heron).

For proof of this, one only needs to look at and follow the link that
appears at the bottom of his post and the bottom of his, so called,
"critique" page.

It's perfectly fine that this guy wants to rally support for his "new
language" but he should do it a constructive way, perhaps a "mine vs.
theirs" approach would better support his cause his cause.

The "critique" would be more aptly named, "Why I hate C#"

My 2 cents
Brian W

 

[Frank Oquendo]

For proof of this, one only needs to look at and follow the link that
appears at the bottom of his post and the bottom of his, so called,
"critique" page.

Or you could just read the very first sentence:

<quote>
This is not a formal critique of C# but more of a personal opinion piece and
a defence of the for my own programming language Heron.
</quote>

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Bret Pehrson]

There doesn't need to be a comparative language to be critical of this one.

 

[christopher diggins]

1) Unsafe Code - Sometimes you need it, plain and simple.

Then I would argue it illuminates weakness in the language to begin with.

2) Attributes - Huh? Take for example FileIOPermission 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.

You haven't eliminated ugly branch logic. It is just hidden in the
attribute. Because something has been moved into a library and looks pretty
is not sufficient. There are other attributes that people write that are a
complete mystery making understanding someone else's code a real headache
because the branch logic is no longer apparent.

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.

Yes, but when they use them wrongly it is the biggest nightmare you can
imagine. (i.e. My code doesn't work, oh I see the problem this harmless
little attribute is written wrong).

3- Garbage Collection - Yes, all of the benefits you get from Managed code
aren't totally free.

Yep. And some of us just plain don't want a GC. Hence the title, "Why I
don't use C#"

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?

The destructor gets called when the Garbage collector deallocates the
memory. When will that happen?

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

Plus user defined structs.

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?

A guarantee of immutability of object across functions and modules is
important for designing well behaved and correct software.

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?

Okay, I definitely don't have enough ammo to back this one up.

9-Polymorphism - Why can't you use multiple Interfaces?

You can, but you have to redeclare every function in every class that
implements an interface. That can quickly become really unmaintainable with
sophisticated 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?

I am just saying that they missed the boat, and are now grafting it on
painfully with some important features missing.

11- Source File Layout - Can't you get all of that information via
reflection or using the CodeModel?

Yes you can. I meant parsing as in reading source code is hard to do.

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?

A language has a responsability to try and make it difficult to write bad
code.

Besides, if they tried stopping this, there'd be so many VB
Programmers screaming bloody murder it wouldn't be funny.

Replace them all with properties I say (public fields not the VB
Programmers)

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.

C# is a new language, it doesn't need to support legacy code. It is
incompatable with all other languages.

Special Primitives - Once again, so what?

I can't write my own.

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.

What I am referring to is that assigning to a property behind the scenes can
map to a Set function call.

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

Nope. All of these issues are part of the C# specification.

 

[christopher diggins]

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

what I want is a truely java-like write once run everywhere

You mean write once, and run everywhere where there is an up to date,
efficient and correct VM installed. "Write once run everywhere" is simply a
marketing catch phrase with no true meaning.

 

[Bret Pehrson]

*** NO MULTIPLE INHERITANCE ***!!!

Biggest fault of C# in my opinion.

 

[christopher diggins]

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.

Yes I agree there are work-arounds for a good programmer. But nothing to
prevents less experienced programmers from going in and doing a heck of a
lot of damage. My problem is using other people's code, which is crucial for
any kind of serious development.

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 DoASensitiveThing()
{
if (!LookUpUserAuthenticationInfoAndCheckHeHasProperRoles())
throw new AccessDeniedException();
// do the actual logic here
}

// attributes version
[RolesRequired("Admin")]
public void DoASensitiveThing()
{
// 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.

That is fine, but then what can appear to be an error in the "actual logic"
could be an error in the attribute itself. Attributes are fine to use in
trivial well written cases, but when everyone and their dog start writing
attributes there will be some serious problems debugging and understanding
non-trivial software.

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.

Yes I should not have compared attributes to macros in retrospect. I have
updated the critique. But I do wish to say an attribute can just as easily
have unexpected side effect which can be difficult to uncover if it is badly
written.

Regards,
Sami

Thanks for the good insight and useful points.

 

[christopher diggins]

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.

..NET has nothing to do with C#. C# is a new language specification with no
support for any kind of legacy code whatsoever.

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.

In Windows world maybe.

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.

Which dreaded buffer overflow are you referring to? How is allowing structs
on the stack okay while objects aren't?

 

[Humanity]

Oh, it's not that important.

*** NO MULTIPLE INHERITANCE ***!!!

Biggest fault of C# in my opinion.

 

[Jon Skeet [C# MVP]]

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

Somewhere, there *has* to be unsafe code - otherwise you'll never be
able to access the file system etc. Where do you draw the line?

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.

I'd be interested to see it.

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

If you have a magical language which lets people write libraries but
*not* let them make mistakes in those libraries, I'm all for it. I have
yet to see such a beast.

It does lead to the boxing/unboxing problem.

Not necessarily - there's no boxing/unboxing

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.

If you're planning to use the type, you need to know considerably more
about it anyway - why shouldn't you know whether it's a value type or a
reference type? In practice, I find that value types are rare, beyond
those supplied by the framework itself.

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.

Yes, true. Mine was flawed due to a typo, though, rather than being an
actually important flaw

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?

No, because you can write your own classes which are immutable. What
you can't do is have a class which has some mutable instances and some
immutable instances.

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.

The point is that the logical realm of WriteLine is Console -
Console.WriteLine isn't to do with "the system", it's to do with the
console.

If you want to write code with very short names though, don't let me
stop you - I just hope I don't have to read your code. The names in
..NET are generally descriptive without being overly long.

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.

But a namespace is precisely that - a space for names. They're not a
"space for stuff there isn't room for elsewhere". Namespaces are
primarily about grouping things and avoiding name collisions.

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.

Even then, they really don't, in my view...