473,842 Members | 1,838 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Another C# critique

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
Nov 15 '05 #1
188 7272
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

Nov 15 '05 #2
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

Nov 15 '05 #3
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
Nov 15 '05 #4
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
Nov 15 '05 #5
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?
Nov 15 '05 #6
> - 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.


Nov 15 '05 #7
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
Nov 15 '05 #8
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

Nov 15 '05 #9
"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
Nov 15 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
3749
by: Long | last post by:
How to include an HTML doc in another HTML doc Problem: to insert the body section of an HTML doc in another HTML document at a specific location. One possible way is to add a WebCharm tag like this: <%@charm:html 20 0 my_services.htm %> When the HTML template is processed by a WebCharm-aware web server, the
19
2561
by: TC | last post by:
Are there any good sites or forums for a web critique? I went to alt.html.critique and it's pretty dead.
9
2290
by: bowsayge | last post by:
Inspired by fb, Bowsayge decided to write a decimal integer to binary string converter. Perhaps some of the experienced C programmers here can critique it. It allocates probably way too much memory, but it should certainly handle 64-bit cpus :) #include <stdio.h> #include <stdlib.h> char * to_binary (unsigned long value) {
39
1947
by: Eric | last post by:
There is a VB.NET critique on the following page: http://www.vb7-critique.741.com/ for those who are interested. Feel free to take a look and share your thoughts. Cheers, Eric. Ps: for those on comp.programming, this may be off topic, but I've posted there because the critique was part of a discussion in that group.
0
9867
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, weíll explore What is ONU, What Is Router, ONU & Routerís main usage, and What is the difference between ONU and Router. Letís take a closer look ! Part I. Meaning of...
0
9709
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10939
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10609
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10308
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7028
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
4498
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4086
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3140
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.