473,842 Members | 1,963 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
188 7282
I would like to transition this thread to a more appropriate newsgroup so
please post any responses in comp.lang.misc, thank you very much.

----- Original Message -----
From: "Philip Rieck" <st***@mckraken .com>
Newsgroups:
Sent: Monday, January 26, 2004 11:26 AM
Subject: Re: Another C# critique
You seem to be championing "Heron" instead of c#, based on the page you
linked to.
That is but one link, the critique has enough meat on its bone to stand
alone. I haven't seen yet any serious attempts to critique the language.
However, the available "spec" for Heron is so bare as to be
un-critiqueable ( for example you mention calling destructors, but not
defining them)
Yes. The published spec is very bare-bones. I need to work on it and I am
actively seeking input and feedback like yours.
However, there are some huge real-world problems already: - here's a very
partial list from a quick perusal
I truly appreciate the input.
-it mentions specifically that there will be no support for concurrency.
So this language can only be used for small tools and hobby applications?
Your implication is that medium and large sized or non-hobby applications
all require concurrency. I disagree.
- 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.
Heron requires the unit name as a preface to any name-clashes.
- 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.
Only variants support RTTI. This is not clear, I realize now.
- 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.
Classes can not derive from other classes in Heron.
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?
Using the external module.
- Memory uses reference counting: what is done about circular references?
There is no garbage collector. Memory must be freed explicitly, this means
that there is no circular reference problem. I will be explaining this
further in a technical paper soon.
- 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)?
The interface does not have conversion operators, only functions. All
operators are considered as being implementation details and hence are found
in classes not interfaces. A small amount of extra work but makes
programemrs think twice about overusing operators on their classes. The
principle is that Operators are best not overloaded unless extremely useful.
- 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.
Streams have a full compliment of functions but only one operator. The core
library does support asynchronous reads (if available on the target OS).
There just can not be multiple entry points into a Heron program.
It seems like a half-baked language.
Don't be mislead by weaknesses in the specification document, there has been
a lot of work gone into the design of this 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.


Thanks for the input on Heron, I appreciate it and will update the spec
shortly to try and address some of the inadequacies you have brought to my
attention.

-
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #21
Jon and Christopher,

For Christopher's example regarding boxing and unboxing:

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

There is only one way that the code above would compile, and that is if
anothertype was derived from sometype. Since value types can not be derived
from in .NET, so it must be a reference type. The state of x is the state
of y, since x is a reference to the same object that y points to.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...
christopher diggins <cd******@video tron.ca> wrote:
> - 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.


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


I'd be interested to see it.
- 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.


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


Not necessarily - there's no boxing/unboxing
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.


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.
- Boxing / Unboxing
<snip>
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 :)
- 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?


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


The point is that the logical realm of WriteLine is Console -
Console.WriteLi ne 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.
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.
Even then, they really don't, in my view...

--
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 #22
Replies inline:
"christophe r diggins" <cd******@video tron.ca> wrote in message
news:Gj******** *********@weber .videotron.net. ..
"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.


1. Why do you have a problem? because they are accomplishing what they
advertise? If you just don't want other people to call unsafe code, then
you can stop it - the CLR supports code access security and verifiability
concetpts that allow you to limit the access of running code, or code you
call (in fact, you have your code set up an appdomain and limit the library
to a small subset of permissions).

2. Then do you have a problem with calling COM objects or native functions
(p/invoke) from C#? Both are much more "unsafe", but both are required to
accomplish many tasks.
- 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.

I've sen dastardly usage of lots of different simple syntaxes from lots of
different languages. People will always write unreadable code. My firm
opinion is that attributes do not signifigantly increase this ability to
write unreadable code, yet provide enourmous value. If you've never
utilized custom attributes, you may not realize the functionality they
provide, and the difficulty in implementing this functionality without them.

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


This is a no-win argument. I like GC'd apps, because of my time having to
write and maintain large libraries in C++ (where the #1 through #10 problems
were memory leaks or other memory management issues). Some people feel
strongly that they can manually code much better memory management in each
application. I normally smirk when I hear it, because I've looked at lots
of code with problems, but it is possible. However, I applaud them for not
making it optional. Look at managed C++, and the trials of writing
unmanaged and managed object code side by side.
- 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.

A poorly written library is going to be poorly written, no matter what. in
a RAII-type world, they can make mistakes. in the IDisposable workd, they
can make mistakes.... are you saying that c++ is less prone to resource
management mistakes by library vendors than c#?
- 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.


You mean using value types leads to boxing. using reference types for
everything removes boxing, as they are not boxed.
- 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.

No, x will not be any of the above, no matter what sometype is. It will not
be an instance of sometype, an intitialized instance, or a pointer to
anything.

sometype x;
What that line says (clearly) is that I have a variable of type "sometype"
named "x" to be initialized later.

It may be an "int" (or a struct) , in which case the actual memory it
contains may (or may not) contain zeros, but it doesn't matter, since I cant
read the value until I initialize the variable.

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


Sort of. By immutable do you mean that 1) all properties are read only? or
2) do you mean that you want to create a field of some type that has public,
writeable properties, and mark it const so that nothing that you pass it to
can modify those properties?

I'm sure it isn't 1), as that would mean you haven't used c#.

If it's 2) then a class marked "const" would have to be written to support
it anyway - in that case why not use a factory pattern and access modifiers
and stick to well resarched and documented practices instead?
[snip out things which I may not agree with but have no response to at this
time.]
- Polymorphism through Class Inheritance
- Interface Delegation


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

I don't think they are all that valid, but I may be wrong.
Wouldn't "interface delegation" simply be a shortcut of implementing each
interface function and calling a member object's methods instead? While
this syntactic sugar might be nice, it really doesn't give you anything
else. In fact, with explicit implementation, you can "delegate" one
interface to different members based on call or on condition.

However, removing class inheritance means that you must treat all your
parameters as an interface, not an object if you want to support
extensibility. (since there is no "is-a" type relationship). That means
that you must have an interface tree as large as your object tree. If your
interfaces can not support inheritance, then have to implement every
interface in the tree in each object as well.
- Interface Extensions


Yes, that could be nice.


Interface extensions: do you mean like to abstract classes with abstract
member functions, except in interfaces? I would argue that when you start
writing implementation in an interface (even if it's just calling members of
the same interface), it is now a class.
[snip]
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


C# does have some faults. I agree on public fields, especially... but it
has fewer than any I've used in production. And it does come with some
shackles (MS-only, CLR-only). But as that's where I am anyway they are not
issues to me (and are in fact plusses).

But I'll use it until a better alternative comes along. And from what I've
read on your site, Heron is not it. Perhaps it will be. I do wish you
luck. However, when and if that happens, promote by telling me why I
should use it instead of the "I hate c#" rant. Give me a reason to want to
try it. Give me a Pet Shop example with less code and/or more readable
code. Tell me how I can use it to go home earlier at night.

Nov 15 '05 #23

"Brian W" <brianw@gold_de ath_2_spam_rush .com> wrote in message
news:OP******** ******@TK2MSFTN GP12.phx.gbl...
OK ladies and gentlemen, don't feed the troll.

This guy is just trying to gather support for his language (Heron).
Yes this is part of my motive. I also want to look critically at other
languages and have my ideas exposed to the best kind of critical reading
available.
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.
Proven.
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.
Identifying potential weaknesses in a language is productive. Or should I
just roll over and say C# is just fine. At least I am being honest with
regards to my bias as opposed to thinly disguising it in a "mine vs theirs
approach".
The "critique" would be more aptly named, "Why I hate C#"


Are you suggesting that the critique is entirely baseless? I would
appreciate it if you could have shown some kind of weakness to my article
rather than criticizing it because I link to my own language at the bottom.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #24
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...
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?


Best left to a standard library I would suggest, don't let every amateur
programmer hack using unsafe contexts. I think unsafe context is a cheap
workaround.
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.
That is just a bait and switch argument. It is an over-generalization of
what I am trying to suggest. A high level language has a responsability to
make it more diffcult for programmers to shoot themselves in the foot as
opposed to easier.
> - 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.


Not necessarily - there's no boxing/unboxing


I meant boxing/unboxing is needed to unify a type system that is un-unified
to being with (i.e. every object is a reference)
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.
I think it is easier for a programmer when there is a consistent treatment
of types. Otherwise you need to look up too much in order to decode
statements
like : x = y;
Yes, true. Mine was flawed due to a typo, though, rather than being an
actually important flaw :)
I still significantly dislike boxing.
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.
Okay. I stand corrected again. I can't have classes with both mutable and
immutable instances. That is still the same problem as was so clumsily
trying to refer to previously.
The point is that the logical realm of WriteLine is Console -
Console.WriteLi ne isn't to do with "the system", it's to do with the
console.
Scope is different than logical realms. Every programmer should be able to
decide his/her own problem realms and place things accordingly where they
find most appropriate. For example in my software I always include a general
purpose unit (I mostly use Delphi) with a couple hundred useful utility
functions. It is nice to not always have to preface them with some kind of
"Utility.".
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.
And so are pascal style units. There is no reason to force programmers to
prefix everything. Leaving it as an option is better. Globally scoped does
not automatically mean bad nor does it mean automatically unresolvable name
clashes.
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.
Even then, they really don't, in my view...


That is your perogative.

-

Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #25
christopher diggins wrote:
"Sami Vaaraniemi" <sa************ ***@jippii.fi> wrote in message
news:bv******** **@phys-news1.kolumbus. fi...
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.


Which is true for just about every language feature. Writing good programs
always has required and always will require thoughful use of the language
features one has at his/her disposal. As always: A fool with a tool (or C#
for that matter) is still a fool.
One *can* write much more expressive code because of C# attributes and
that's all that matters. BTW, the same is true for C++ macros (much less
frequently though).

Regards,

Andreas

Nov 15 '05 #26
Sorry about editing the original post so heavily, most of the stuff I
snipped was because I was agreeing with Philip and need to update my
critique :)

"Philip Rieck" <st***@mckraken .com> wrote in message > "christophe r diggins"
<cd******@video tron.ca> wrote in message
1. Why do you have a problem? because they are accomplishing what they
advertise? If you just don't want other people to call unsafe code, then
you can stop it - the CLR supports code access security and verifiability
concetpts that allow you to limit the access of running code, or code you
call (in fact, you have your code set up an appdomain and limit the library to a small subset of permissions).
This is true.
2. Then do you have a problem with calling COM objects or native functions
(p/invoke) from C#? Both are much more "unsafe", but both are required to
accomplish many tasks.
I see your point but unsafe contexts across languages is different than
unsafe contexts within the same language. I do see some utility in unsafe
contexts. I am just not convinced it is the best solution.
> - 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.

A poorly written library is going to be poorly written, no matter what.

in a RAII-type world, they can make mistakes. in the IDisposable workd, they
can make mistakes.... are you saying that c++ is less prone to resource
management mistakes by library vendors than c#?
I would say that C++ with non-deterministic finalizers, would be a much
worse C++. That's all.
> - Type / Reference Types
No, x will not be any of the above, no matter what sometype is. It will

not be an instance of sometype, an intitialized instance, or a pointer to
anything.

sometype x;
What that line says (clearly) is that I have a variable of type "sometype"
named "x" to be initialized later.

It may be an "int" (or a struct) , in which case the actual memory it
contains may (or may not) contain zeros, but it doesn't matter, since I cant read the value until I initialize the variable.
My error, I didn't realize that a struct doesn't have default constructors.
I also managed to get myself confused in a couple of other respects.
By immutable do you mean that 1) all properties are read only? or
2) do you mean that you want to create a field of some type that has public, writeable properties, and mark it const so that nothing that you pass it to can modify those properties?

I'm sure it isn't 1), as that would mean you haven't used c#.

If it's 2) then a class marked "const" would have to be written to support
it anyway - in that case why not use a factory pattern and access modifiers and stick to well resarched and documented practices instead?
You are arguing then that const is pointless? And it seems you are
suggesting it is not a well researched and documented practice?
> - Polymorphism through Class Inheritance
> - Interface Delegation

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

I don't think they are all that valid, but I may be wrong.
Wouldn't "interface delegation" simply be a shortcut of implementing each
interface function and calling a member object's methods instead?


Yes that is exactly what it is.
While
this syntactic sugar might be nice, it really doesn't give you anything
else.
It saves you writing out potentially hundreds of trivial interface function
implementations for every class.
In fact, with explicit implementation, you can "delegate" one
interface to different members based on call or on condition.
Yes explicit implementation is not replaced by delegation techniques but
complimented.
However, removing class inheritance means that you must treat all your
parameters as an interface, not an object if you want to support
extensibility. (since there is no "is-a" type relationship). That means
that you must have an interface tree as large as your object tree.
As large as your *original* object tree. The interface tree supplants the
object tree.
If your
interfaces can not support inheritance, then have to implement every
interface in the tree in each object as well.
Interfaces can support inheritance in Heron, Java, C#, Delphi and most all
other languages with interfaces.
> - Interface Extensions

Yes, that could be nice.


Interface extensions: do you mean like to abstract classes with abstract
member functions, except in interfaces? I would argue that when you start
writing implementation in an interface (even if it's just calling members

of the same interface), it is now a class.
It is similar to an abstract class with function defintions but it
differentiates itself by not allowing member data.
But I'll use it until a better alternative comes along. And from what I've read on your site, Heron is not it. Perhaps it will be. I do wish you
luck. However, when and if that happens, promote by telling me why I
should use it instead of the "I hate c#" rant. Give me a reason to want to
try it. Give me a Pet Shop example with less code and/or more readable
code. Tell me how I can use it to go home earlier at night.


I will take you up on that offer at some point soon in the future Philip and
thanks for the good wishes.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com
Nov 15 '05 #27
christopher diggins <cd******@video tron.ca> wrote:
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?


Best left to a standard library I would suggest, don't let every amateur
programmer hack using unsafe contexts. I think unsafe context is a cheap
workaround.


Most of the time, libraries *won't* use unsafe code, and as another
poster pointed out, you can always make sure that you *don't* use
unsafe code using the attributes you so dislike.
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.


That is just a bait and switch argument.


Not really - it's a "criticisin g something for not doing the impossible
is unreasonable" argument.
It is an over-generalization of
what I am trying to suggest. A high level language has a responsability to
make it more diffcult for programmers to shoot themselves in the foot as
opposed to easier.


And C# does that. It just doesn't make it *impossible* for programmers
to shoot themselves in the foot.
Not necessarily - there's no boxing/unboxing


I meant boxing/unboxing is needed to unify a type system that is un-unified
to being with (i.e. every object is a reference)


Yes, boxing is needed for that. I really don't see there's that much of
a problem though.
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.


I think it is easier for a programmer when there is a consistent treatment
of types. Otherwise you need to look up too much in order to decode
statements
like : x = y;


All you've got to know is whether or not x is of type "object" and y is
a value type. Other than that (assuming implicit conversions aren't
going on, which are a whole different matter), there won't be boxing.
Do you often have that situation? I rarely use variables of type
"object" myself.
Yes, true. Mine was flawed due to a typo, though, rather than being an
actually important flaw :)


I still significantly dislike boxing.


It's something to be avoided where possible, but I don't think it's
nearly as bad as you make out.
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.


Okay. I stand corrected again. I can't have classes with both mutable and
immutable instances. That is still the same problem as was so clumsily
trying to refer to previously.


Right. Lack of const-correctness is indeed a shame. I believe MS are
looking into this for a future version, and I know there's a modified
version of Rotor available which *does* support it.
The point is that the logical realm of WriteLine is Console -
Console.WriteLi ne isn't to do with "the system", it's to do with the
console.


Scope is different than logical realms. Every programmer should be able to
decide his/her own problem realms and place things accordingly where they
find most appropriate. For example in my software I always include a general
purpose unit (I mostly use Delphi) with a couple hundred useful utility
functions. It is nice to not always have to preface them with some kind of
"Utility.".


I disagree for almost all cases, as it shows exactly where the method
is coming from, which I believe is a good thing. I believe C# v2 will
have something to satisfy you though, just as Java 1.5 will.
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.


And so are pascal style units. There is no reason to force programmers to
prefix everything. Leaving it as an option is better. Globally scoped does
not automatically mean bad nor does it mean automatically unresolvable name
clashes.


No, but it makes them more likely, and makes the code harder to
understand to someone not intimately familiar with the codebase.

--
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 #28
"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 :
[snip] 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
Unsafe Code:
Mixing regular code with unsafe code means that any security and robustness guarantees can too easily be overridden. A garbage collector which is overridden is pointless. The problem surfaces when multiple people work together on a large project.
Ideal - if everything were in managed space. However, and I find this to be
one of Java's weaknesses, was it's interface to existing code (most of which
is, of course, unmanaged). Working with unmanaged code is sometimes better
suited to unsafe code blocks. However, it's not true that the GC is
circumvented by unsafe code. Unsafe code requires pinned variables in a
local scope. You have to do something horribly wrong to undermine the GC,
and that takes conscious effort on the part of the developer in most cases i
can think of. The crux of this issue is flexibility vs. forced robustness,
and keep that in mind, because I'll revisit it soon. In the meantime,
realize that unsafe code requires a special compiler switch. If you really
don't want your team working on large projects to use it, then don't allow
that switch to be used. Problem solved.
Attributes:
Code quickly becomes extremely illegible when attributes are used. Attributes result in essentially an obfuscation of the language specification and expected behaviour. Debugging code becomes trickier when attributes have potentially subtle side effects.
It may seem that way to you, but that may be due to your familiarity with
large branches of visible code doing all the work, and this is a different
paradigm. Many languages now use declarative elements and those that didn't
are recently seeing its adoption. However, the obfuscation part hardly
seems like a justifiable case for your argument against attributes, because
if we were to replace "attributes " with a compiler or library function, you
would essencially end up with the exact same results - a small tag of code
whose explicit details you are not privy to. In that respect, any language,
other than assembly with no macros, whether it has declaritive elements or
not would be guilty of the same crime.
Garbage Collection:
You are effectively forced to use garbage collection. Turning off the garbage collection in C# can lead to extremely subtle and hard to find bugs due to a mix of garbage collected and non-garbage collected code. Turning off garbage collection can only be done by switching to an unsafe context with all of what that implies.
I see several problems with this argument. First of all is the inconsistancy
of your arguments. Remember the first point I made above that I said i would
revisit? You wanted the language to be less flexible in favor of enforcing
robustness (which you are happy to point out elsewhere in your dissertation
as well). Here, you are completely reversing your position. What MS has
done, is evaluate the top reasons in existing languages (primarily C/C++)
for bugs that both slip notice and cause tremendous problems. As you might
already have guessed, manual memory management is at the top of the list. GC
is the only way (that I know of, or that has been proven to date) to solve
this issue. This is a mojor point of robustness, and I'm unlcear as to why
you would be in favor of robustness above, but not here. Also, there is no
way to "turn off" GC in C# (otherwise, you wouldn't be forced to use it,
right? - seems like a contradictory statement there), and switching to
unsafe mode will not turn off the GC. I have a feeling you are also
confusing the issues between managed and unmanaged code here (which is
completely different from safe vs. unsafe code). As Inigo said to Vezzini,
"I do not think this means what you think it means."
C# allows non-deterministic destructors:
Garbage collection with destructors means the destructors can be called at unpredicatable moments during execution.
That is the nature of GC. The thing to remember is: you shouldn't use
destructors for deterministic management (eg. clean-up) of resource (that's
what Dispose is for). Destructors are there as a safety net in case a
consumer doesn't explicitly call Dispose. The Dispose pattern in my opinion
is valid, because the only way to get deterministic finalization, is if the
consumer knows he needs something to be managed "now" - so he MUST call
something... whether that something is a memory deallocation keyword or a
Dispose function is rather irrelevant. Bottom line: if you want to know that
clean-up code is being called "now", use Dispose. That is deterministic. Of
course, C# isn't the only language that uses a GC and deals with the same
issue, but I'm betting you don't like any of them either ;-)
Objects can't exist on the stack
We are forced to use structs if we want to create an object which exists on the stack. This can cause problems for users of a library which has locked in an object implementation.

I'm not sure your example fits the problem in this case. For starters, if
that's the only problem with objects being limited to the heap, then hell..
what's the problem? :-) Your example only illustrates that you shouldn't
poorly design class libraries, and the importance of not carrying
implemenation details across boundries (which is why we deal in Interfaces
at that point). Secondly, I'd like to see an example of how this impacts the
consumer of said class library. As far as the user knows, he is passing a
parameter of a certain type to a member. If that parameter changes from
reference type to value type, does that really impact him? His code is going
to more or less look exactly the same from his point of view for that member
invokation.
But lets look at the flipside of the coin. Why would you want objects on the
stack to begin with? The primary reason for C/C++ programmers is that the
speed of heap allocation sucks in comparison to stack allocation. That
limitation doesn't exist in .NET. Heap allocation in .NET requires only the
increment of the allocation pointer, making it almost exactly the same as
stack allocation in terms of performance. To make reference types available
on the stack, you'd have to change GC infrastructure, which would
effectively make reference type allocation on the stack SLOWER. In addition,
value types are rather small in comparison with reference types, especially
if you consider strings, which make up the majority of data in a program. Do
you really want a programmer to accidentally put that on the stack? IMHO,
this isn't a sticking point at all for or against C#.
Type / Reference Types
A type decides whether it will be on the stack or the heap. Which means a programmer has to be aware of each types specific semantics when using it to know whether they are passing things by reference or by value. This leads to subtle and confusing bugs.
Actually, types don't reside on the stack or heap, variables do. Secondly,
types don't decide where the allocation goes, the runtime does.
Again, I'm curious as to what sorts of bugs this would cause.
Boxing / Unboxing
The semantics of boxing and unboxing are subtle and confusing. There is a problem of needing to know too much information about a type to decode the semantics of a simple assignment. Boxing is a feature designed to compensate for the fact that objects must be used by reference.

Quite the contrary, IMO. Boxing/unboxing allows the programmer to need to
know a lot LESS about whether a type is a reference type or not in order to
use it in the context of a reference type (for example, the common
assignment of value types to a more general reference type reference). If it
were not for boxing/unboxing, the programmer would have to be far MORE aware
of the details of the type implementations and code such scenarios
SEPARATELY.
Mutability
C# does not allow declaration of immutable instances of user defined objects.

I understand what you want to do here - create a const instance of a class.
Fair enough, but the semantics could get ugly. First of all, this wouldn't
truly be CONST unless the compiler had a way to create literal instance data
imbedded in the program (as it can easily do for numbers and strings because
it's programmed to know how to do that). You can argue that serialization
might do the trick, but then you'd be limited to only serializable objects
being const. If the compiler is unable to do this, it would have to write
code behind the scenes to create an instance at runtime, which isn't truly
const and you'd be in no better position than using the "final" modifier in
Java, which only prevents you from modifying the value. But assuming you
were able to freez-dry a literal instance (and have a mechanism for the
programmer to specify the data for it in the first place), you could then
run into issues of possibly bypassing class behaviors associated with
constructors - and if you didn't, would it be truly const? This is one of
the reasons that value types get literals and reference types don't - value
types have no constructors.

Also, the lack of literal declarations doesn't mean you can't have immutable
objects. You can certainly program immutable objects in C#. Again, you might
want to check your verbiage here. One thing doesn't necessarily mean the
other. And for the sake of a good critique, this can show lack of
understanding of the principals you are critiquing against.
Classes as Modules and Programs
C# allows static information within a class and not outside of one. Therefore a class in C# has concepts that are a hack designed to compensate for missing modules. Classes and modules are very distinct concepts that deserve to be treated as seperate identities. When we do so, as in Heron and Object Pascal, the semantics of classes is simplified somewhat. One example of where not being allowed to place data into the global scope of a namespace is noticeably lacking : using System;
class Hello
{
static void Main() {
Console.WriteLi ne("hello, world");
}
}
The System namespace can not export a function named WriteLine it can only export static classes. A static class with only static data and static methods should either be a module or a program. It could be argued all static data should occur outside of classes since it is not directly related to objects themselves.
Not sure I agree completely with you here. First of all Classes and modules
are both holding containers for members (whether data or functions). The
difference is that modules cannot have distinct instances, and classes can
(or not, if you're dealing with static members) - in effect being perfectly
capable of performing both roles. Your gripe seems to be more about the
invokation syntax, which is purly compiler syntactical sugar and a few rules
about name resolution. For example, VB.NET allows you to create a "Module"
(thusly named), which (for the reasons i stated earlier) is really just a
static class that contains only static members (and you don't have to
specify that, and they can't be changed to instance members either). The VB
compiler also allows you to invoke said members without qualifying it to the
module's (class') name - in essence letting you "export" what appears to be
a global function to the consumer. That could certainly be in C# as well,
but honestly, it's a matter of personal preference at that point. And there
are a lot of people that prefer it the way it is rather than the way VB.NET
does it. For starters, you are introducing a level of ambiguity and issues
revolving around name resolution that otherwise wouldn't be there... and for
a guy who doesn't like ambiguity, this argument seems rather contradictory
with your previous line of thinking.
Polymorphism through Class inheritance
C# supports polymorphism only through class inheritance. Class inheritance does not encapsulate code as well as interface delegations. Interface implementations can not be delegated to member fields. Every time you want to implement an interface you must explicitly write all of the functions.

That is a completely false statement as worded. C# only allows you to
inherit from one class (no multiple inheritance is even possible).
Everything else *is* interface implementation. It is perfectly legitimate to
inherit an interface (or many) and not inherit any class at all. However,
I'll grant you that the member delegation is more limited than some other
languages, including VB.NET, which allows more explicit control over which
members map to which interfaces. Again, this argument as stated appears to
be extremely misinformed, lessening the validity of the critique.
C# Missing Template Template Parameters
In C#, a generic type parameter cannot itself be a generic, although constructed types may be used as generics.

Remember that generics in C# aren't macro-type replacements as is the case
in C++. There are resolution and type safty issues with regards to allowing
this. There was a rather good explanation in one of the blogs (probably
reachable via C# Corner).
Late Added Generics
By adding generics so late, among other things there is the pointless redundancy of having two kinds of arrays. The int a[]; and array<int> a;
Not a good argument at all. First of all, few languages support generics to
begin with... and some roughly equated to C# have had generics on the
drawing board for years and haven't even gotten there yet. Considering the
priorities and the grand scope of .NET in its entirety (not just C#), the
progression has actually been very fast, especially if you take all the
functionality into account. Note that the language designers actually had a
draft of how generics would work within the scope of the CLR/CLI during
the .NET Beta. But where the argument really falls through is
that having two arrays is *not* pointlessly redundant. Why go through the
gernerics mechanism if you don't have to - especially for types which the
compiler already knows how to build type-safe arrays for?
Special Primitives
Special rules exist for so-called "primitive" types. This significantly reduces the expressiveness and flexibility of the language. The programmer can not add new types that are at fully at par with existing primitives.
What on earth are you tryign to do with user-defined types that can only be
done with primitives?
Remember that the compiler has no earthly idea what to do with types nobody
has written yet...
You're going to need one hell of a good example to justify this one (in
fact, the whole page could do with a LOT more concrete examples to explain
what you're trying to get at). And again, C# isn't the only language to do
this. Most languages are like this... though again, i'm betting you don't
like any of them either.
Source File Layout
C-Sharp code is not readable without automatic documenting tools or editor. It takes a long time to read a source file and find out what classes are included and what the member fields and methods of those classes are. This promotes an unstructured coding style and often leads to bugs that are not immediately obvious without reading the automatically generated documentation.
I'm sure you find it unreadable, but i'm betting C# developers find it
perfectly readable ;-)
This is like COBOL programmers saying they think pascal files are
unreadable, or vice-versa.
I'm not sure your cause-effect statement holds much water either.
And if it's truly that unreadable, what on earth is your suggestion? C# is
about as readable as any C-derived language will ever get. If you don't like
any C languages, why are you even critiquing C# specifically?
Public Fields
Classes can expose their fields as being public. This violates the encapsulation principle of objects.

Oh Dear Lord! The humanity!!! In all seriousness, if C# didn't allow it,
someone just like you would come in and complain that it didn't. All the
encapsulation overkill aside, there are legitimate reasons for exposing
public fields - primary of which is the ability to expose a field whose
value is unlimited in the scope of its range, without taking the performance
hit of going through an accessor/mutator method. And before you cry
"HERASY!", remember, best practices are there to stop people who can't think
from doing dumb things - not there to prevent people from thinking.
Is it a property or is it a field?
Are you setting a field named m or are you calling a property which leads to a function which can throw an exception? A language should allow only properties or only public fields but having both gives us the worst of both worlds.


If a tree falls in the woods, and nobody is around to hear it, does it make
a sound? If you use proper exection handling, does it matter?

As for the overall "critique", you need to cut out the personal opinion
issues, and stick to good empirical data analysis and facts. The problem
with programmers and techies in general is that they fall into an almost
religious stupor about defending or bashing technology, facts and scientific
analysis be damned. Sadly, that just makes hordes of fodder for marketers.
While I could see some potential in a few of your points, elminating the
personal preference issues for the sake of a truly unbiased and worth-while
critique would leave you with a rather slim list. Your page stopped being a
critique and started becoming a soapbox RANT at your last paragraph, so i
won't even justify that part's pathetic existance by commenting on it. So in
essence, your fear of being called a flame-bating troll is not only
possible, but extremely likely. When you add to that the fact that you
posted it in this group, one can only wonder why else you would even bring
it up? If you "honestly want to improve on the critique", then consider
carefully what i said - especially about the ranting. You ran off the tech
rails and right into the blind-pundit/marketer path (take your pick). People
can argue over a true critique, but its merits will weather those arguments
unabashed and faultless when it is founded in pure fact. I can't say that
about
yours. And if you are promoting a product under these ideals, I certainly
wouldn't do business with you. If you have a bone to pick with MS, you
certainly have the right to do so, but don't disguise it as anything less.

-Rob Teixeira [MVP]
Nov 15 '05 #29
>> A poorly written library is going to be poorly written, no matter
what. in a RAII-type world, they can make mistakes. in the
IDisposable workd, they can make mistakes.... are you saying that
c++ is less prone to resource management mistakes by library vendors
than c#?


I would say that C++ with non-deterministic finalizers, would be a
much worse C++. That's all.


Why? Are you suggesting that GC, Finalization and Dispose is more
error-prone than C++ style reference-counted pointers and RAII?

Regards,

Andreas

Nov 15 '05 #30

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
9715
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
10942
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
10310
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
9452
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7855
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5696
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4499
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
4088
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3142
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.