A beautiful language ruined by generics
Hot Topic
- How to retrieve email attachments programmatically?
- passing data from a form to another
- object comparison using < or >
- how to do double click operation on a picture box in c#
- Get a list of Delegate on Event
- urgent~~~!!!MESSAGE BOX CANNOT DISPLAY.....
- Using C++ Interop in C#...... Help....
- EventHandling question
- How do I organize my code in small segements that I can minamize??
- How do I move my records in one dataset into SQL database with field matching?
A beautiful language ruined by generics
Robert Winter
I've read all your arguments. I see good points of each side. Thank you for letting me enjoy this article.
It seems the question is for C#'s code readability v.s. code reusability.
As a solution developer I prefer not to use generic or template because my problem domain resides in a specific classes or types. However if I need to maintain or to develop a library, I probabily look into generic stuff.
Hmm...
beelzeboris
It is true that templated code requires a little more knowledge to read than other C++ code. That's the difference between beginner and intermediate, IMO
>Generics are a really simple concept - mainly syntactic sugar to deal with the lack of a unitary object hierarchy in C++.
That's just plain not true. Regardless of if everything was derived from a common object class ( which is not true even in C# ), generics provide type safety a lot more than they provide some sort of unifying concept - one could create containers of void * in C++, but why would you want to That's without considering the stuff C++ can do with partial template specialisation to turn templates into class factories.
>In a language like C#, where type information is built into every assembly, they are totally unnecessary.
Just plain wrong. It's my opinion that a fatal flaw of C# is that until 2.0, containers have not been type safe. I can't wait for that to change.
>You can also make your own strongly typed collections (which is all the compiler is doing for you anyway with generics) without sacrificing the clarity and self-documenting nature of staying within the object hierarchy.
There is no sacrifice involved, I am at a loss as to why you think otherwise.
>It's bad enough that C# shipped with operator overloading - adding generics adds insult to injury.
Had C# not shipped with operator overloading, it would just be another toy language. Perhaps you need to take a class or something, and bring your skills to a level of being able to benefit from these sort of features, instead of just being confused by them
Bruce Williams
It is true that templated code requires a little more knowledge to read than other C++ code. That's the difference between beginner and intermediate, IMO
For every templated method you have to track back to a completely new type system, created entirely outside of the object hierarchy. A naming convention can mitigate this but only so far. Since everything is an Object it is totally unnecessary. All that time we spent mastering templates was due not to the brilliance of templates but the lack of a unitary object hierarchy in C++.
That's just plain not true. Regardless of if everything was derived from a common object class ( which is not true even in C# ), generics provide type safety a lot more than they provide some sort of unifying concept - one could create containers of void * in C++, but why would you want to That's without considering the stuff C++ can do with partial template specialisation to turn templates into class factories
Which types in C# are not derived from System.Object ValueType extends Object. Think about what we mean by type safety - this is largely a matter of determining which operations are supported by a given object. This is exactly the purpose of an interface - a contract guaranteeing certain behavior. If you want collections which guarantee that elements in the collection support certain operations then make a strongly typed collection of interfaces.
When the compiler processes code involving a template all it is doing is recreating another version of the template with the types of the actual parameter. It smacks of hackery - it is literally automated cut and paste reuse.
There is no sacrifice involved, I am at a loss as to why you think otherwise.
The very idea of templating encourages sloppy description. After all, the templated parameters are just placeholders - why bother to name them descriptively Having the compiler generate versions of a template as needed is a stopgap until you have a language that supports interfaces and has a unitary object hierarchy. C# has those and has no need whatsoever of templates.
Had C# not shipped with operator overloading, it would just be another toy language. Perhaps you need to take a class or something, and bring your skills to a level of being able to benefit from these sort of features, instead of just being confused by them
User defined operator overloading causes problems because the semantics of applying an overloaded operator to user defined types are not obvious or self-documenting. They're also often conflicting depending on the whim of the person overloading the operator. I know what int1 + int2 means because it's a part of the language. I know what string1 + string2 means because it too is a part of the language. What does Circle1 + Square1 mean What does it even imply How many different meanings should be stuffed onto a single symbol when you can accomplish the execution of behavior on an object with a method Using a method forces the coder to come up with a name - which makes it that much more likely that the code will be self documenting (especially for the poor guy who has to come along and maintain it).
Remember, a major reason to have source code instead of writing programs in, say, MSIL, is to convey the meaning of the program in a way that is easier for a human being to understand (and fix, maintain, improve, etc...). There might have been a time when templates were the only way to accomplish type safety in a generic fashion. But that time is no longer - there is nothing that you can do with templates that can't be accomplished with C# as it exists today without introducing a ton of extra syntax.
Michael Koltachev
You mean, for example, ArrayList<int> is a new type It's a type of ArrayList, how is it outside the object heirarchy
>All that time we spent mastering templates was due not to the brilliance of templates but the lack of a unitary object hierarchy in C++.
You said that before, and I still maintain that is a bunch of hooey. Do you have any idea of the many things C++ templates can be used for Any pointer in C++ is a void *, so this 'problem' did not exist, anyhow. It's just that a bunch of void * is just as ugly as a bunch of objects.
>Which types in C# are not derived from System.Object
all value types, which are types that are often put into containers, which involves the cost of boxing.
>If you want collections which guarantee that elements in the collection support certain operations then make a strongly typed collection of interfaces.
I did - I always write my own containers because containers without generics suck. It's a hack, I shouldn't have to do it.
>When the compiler processes code involving a template all it is doing is recreating another version of the template with the types of the actual parameter
Yes, but it's done at run time, so it doesn't bloat your code as creating your own classes does.
>It smacks of hackery - it is literally automated cut and paste reuse.
Sorry, but this is plain dumb. Like I said, being able to use PTS in C++ to create class factories is exactly this, compiler cut and paste, and it rocks.
>Having the compiler generate versions of a template as needed is a stopgap until you have a language that supports interfaces and has a unitary object hierarchy. C# has those and has no need whatsoever of templates.
I don't mean to be rude, obviously you will use the language to the degree that you're able to understand it's usefullness. But, why don't you just choose not to use generics, and leave them to those of us who find them useful
I would agree that C# does not NEED templates. we also don't NEED C#, or even C++. Assembler is fine for writing any sort of app you like. But that doesn't mean it supports you as well as a 3GL. And certainly, C# is more about syntactic sugar than C++ is. for-each is a bit of 'sloppy compiler cut and paste', should it be removed also How about properties There's a 'sloppy cut and paste' if ever I saw one. It completely obsfucates if you're calling a method or just returning a value, and of course, it generates it's own magic methods internally. Are you against those too
>User defined operator overloading causes problems because the semantics of applying an overloaded operator to user defined types are not obvious or self-documenting.
Yes, you do need to know what you're doing when you overload an operator. C# makes it a lot easier by forcing things that C++ would just allow, though. And it limits the operators quite a lot, I've been left high and dry with the need for operators that I could not overload in C#.
>What does Circle1 + Square1 mean What does it even imply
Well, any language feature can be abused. Any class library should contain documentation, which you should read. None of this is an argument against features that can be used intelligently.
>Using a method forces the coder to come up with a name - which makes it that much more likely that the code will be self documenting (especially for the poor guy who has to come along and maintain it).
+ and - have clear meanings, and are self documenting when implimented intelligently.
>Remember, a major reason to have source code instead of writing programs in, say, MSIL, is to convey the meaning of the program in a way that is easier for a human being to understand (and fix, maintain, improve, etc...).
Absolutely.
>There might have been a time when templates were the only way to accomplish type safety in a generic fashion. But that time is no longer - there is nothing that you can do with templates that can't be accomplished with C# as it exists today without introducing a ton of extra syntax.
A *ton* of extra syntax Have you even used the beta
If you're this confused/misguided about generics, I have to wonder if you've even seen anonymous methods or iterators, two very powerful features that are bound to get you up in arms, because they generate code and add keywords. However, for people able to learn and evolve, they are powerful features that will leave to elegant solutions.
I'm sorry, I simply cannot agree with you. Templated code is not hard to read, or hard to write. It's just another thing to learn, another reason they call it Computer *Science*.
julio5101989
Funny enough, these neat new features are much harder to understand than templates, and both of them generate heaps of code that you never see, just like generics do.
This discussion is beyond dumb, nothing that you say has any validity as far as I can see, I'm starting to wonder if you're trolling. Either way, you should use both C++ and C# to the level of your skillset. I will continue to do the same. Avoid features that you can't understand or see use for. I wish you well.
wiertmir
ArrayList w/o Generics: Each developer has to make a choice between writing a bunch of repetitive redundant code and having type safety. When you consider the number of developers who will use ArrayList, the effect would be that either MILLIONS of lines of additional code would be written or TENS OF THOUSANDS of applications would be made less stable due to lack of type checking.
What exactly are you doing that requires you to reinvent the wheel over and over by continually coming up with your own collections The whole point of incorporating a collections API into the language is to provide the functionality without requiring you to rewrite it every time. If you're writing tons of your own collections the language SHOULD force you to help the reader out by describing the sorts of types required by the collection (i.e., implementing a strongly typed collection of interfaces).
A really good test of whether or not generics via templates (unnecessary since C# provides generics via a unified object hierarchy) is going to improve the readability of your code is this: What would you call the templated parameter to usefully describe it If you have 50 different custom collections to which you apply exactly the same operations (thereby benefiting from the automated cut and paste that is the implementation of templates by the compiler) differentiated ONLY by name - it sounds like you really DO need a collection of Objects; the contents of the collection are functionally undifferentiated. If they are distinguishable, then interfaces are exactly what you're looking for because you want to guarantee that elements of your collection support whatever operations you plan on applying to them.
No wonder template users use names like __T and ___X; there isn't a succinct way to describe what distinguishes any given type from any other type in the context of their use. But like Steve something or other said in code complete (in a different context) - "The code probably needs to be refactored. And whatever was calling it needs to be rewritten too." QED
degle
I'll take the extra effort, which forces you to think twice about reproducing functionality already provided by the language, over the convenience because
A) if your code is being used by other people then it will need to be maintained
B) self-documenting code dramatically improves maintenance
C) a collection of interfaces is much more self-documenting than a collection of Type T.
Consider this - how much more time will it take someone to understand what your collection contains if you make a collection of Type T objects vs a collection of ReallyDescriptiveTypeName objects If there is very little reason for someone to need to understand the significance of the elements in the collection then you almost certainly do not need to create a strongly typed collection.
"But in C++ you're supposed to create strongly typed collections. That's what all the 'real coders' say isn't it " - C# is not C++. It isn't even C+++. You will find your reputation improve over time if you spend the time to learn how to program C# (instead of writing C++ code for a C# compiler). It will improve because the code you write will be so easy to understand that improving it will be a joy.
If Type safety is what you're after (I certainly understand this AND AGREE - much better to let the compiler inform users of misuse than a phone call at 3am in the morning) then use a custom collection of interface types. Make the interface nice and descriptive. If you find yourself unable to come up with a good way to indicate why the elements of the collection merit a custom collection - then you probably don't need to make a custom collection and will be served just fine with the collections that ship with the language.
In short, making it easy for you to inflate the size of your (probably unnecessary) library does not justify the decreased readability enabled by adding templates to C#. Just say no to template use!
DarkestShadow
"I have never ever needed a strongly typed collection that wasn't either already provided by the language (except in C++) or easily written."
Yes, it's easily written, but you, me, and I dare say 99% of the developers out there have written "easily written" collections. My point, which apparently goes over your head, is that Generics saves time for ALL 99% of us. Yes, a little here, a little there, but it adds up! And it's less code for me to maintain, and decreases the potential for bugs.
"The very idea that I'm going to write a sequence of instructions and apply them to elements whose type I don't know strongly suggests that either I don't know enough about what I am writing or that whatever is using my code needs to be refactored."
Ahh! This is VERY telling. The very idea that you expect to know everything about the types that you are using is ludicrous! Unless your just a beginner. In which case you shouldn't be making judgments about what's "good" or "bad" about a language.
Weevie
Uhmm, none Because I don't have a collection of type T objects. My collection would contain objects of whatever type the collection is DEFINED to hold. I think MOST programmers are smart enough to figure that out.
Wow! Where do I start You contradicted yourself. First you claim strongly typed collections are a "C++" thing and aren't necessary in C#. Then you AGREE that strongly typed collections are a good thing. Then you say I probably don't need them. Which is it
"Inflate" It does quite the opposite! ONE class source instead of multiple sources is "inflated" And (as mentioned above by someone else) C# generates the necessary code at RUNTIME so your DLLs aren't even "inflated".
Quite frankly, I've grown tired of this meaningless drivel. I'll let you have the last word...
hatem elshenawy
It wouldn't be so bad if, in practice, the type being parameterized had an obvious meaning. But we're rarely so lucky in practice. Usually you're looking at a method several levels into the call stack at a point in the method where several operations have already been applied. What is __T supposed to mean after it's been added to __T2, passed as a parameter to __convoluted_func (which takes as parameters __X and ___Y) then divided by __RANDOM_CONSTANT
Think about why template users are so inclined to name their variables in ways that indicate nothing about their purpose or use. It's a placeholder plain and simple. When you're dealing with something that is conceptually a placeholder (instead of, say, a type with a descriptive name) you're naturally not going to put much stock in trying to describe it. That's my big problem with templates - they encourage sloppy description thereby making source code much less self-documenting. Not only do they encourage unnecessarily obscure code - they clutter up the language with extra syntax.
You said that before, and I still maintain that is a bunch of hooey. Do you have any idea of the many things C++ templates can be used for Any pointer in C++ is a void *, so this 'problem' did not exist, anyhow. It's just that a bunch of void * is just as ugly as a bunch of objects.
This is exactly why I'm so disappointed that they've brought this ugly creature from C++ into a formerly beautiful language. An Object reference is not a void * (pointer). Void * means "I have no idea what this thing is pointing to". Since everything in C# derives from Object, referring to a class through an Object reference is just what polymorphism demands. Objects know their type, they have a default string representation and default semantics for equality comparisons. In other words, bringing this kludge from c++ encourages C++ programmers to treat C# as if it were C+++ - to program as if it were still halfway between C and a truly object oriented language.
I have never ever needed a strongly typed collection that wasn't either already provided by the language (except in C++) or easily written. Never. I've written several libraries, I've written several kinds of neural networks, I've written Windows apps, I've written web apps. The very idea that I'm going to write a sequence of instructions and apply them to elements whose type I don't know strongly suggests that either I don't know enough about what I am writing or that whatever is using my code needs to be refactored.
Well, any language feature can be abused. Any class library should contain documentation, which you should read. None of this is an argument against features that can be used intelligently.
Agreed. But some language features lend themselves to abuse. It is not at all clear what the "intuitive meaning" of adding TypeX to TypeY or 2 instances of TypeX together is supposed to do. If the types are anything other than trivial then there are probably going to be several reasonable interpretations for what adding/subtracting/etc.. is going to mean. Adding user defined operator overloading is giving developers too much rope. Software doesn't exist in a vacuum these days; it's everywhere. The hotshot who gets all excited about templates or operator overloading will go a long way to making maintenance and improvement a nightmare. A nightmare it doesn't have to be. If only they used a descriptive name for the operation they stuffed onto +...
Why on earth would an object oriented language without all the baggage of C++ need templates What does defining a type mean if not the creation of a template (one which will be used to create every instance of that type) Templates are redundant and were one of the many features of C++ tacked on to fix earlier bugs that ended up creating more trouble than they're worth (implicit vs explicit constructors anyone )
Please let C++ die the slow miserable death its obesity has merited. Preserve the beauty of C#. Just say NO to templates. :)
BobTheBuild
So you've trawled into the STL source code. What does that have to do with adding generics to C# You cannot add types to one another, now can you divide them. You can't say int + string / myType.
Think about why template users are so inclined to name their variables in ways that indicate nothing about their purpose or use.
Their purpose is clear, it's pretty much self documenting.
An Object reference is not a void * (pointer). Void * means "I have no idea what this thing is pointing to".
I understand the difference between object and void *. However, dynamic_cast allows us to discover type in C++ also.
In other words, bringing this kludge from c++ encourages C++ programmers to treat C# as if it were C+++ - to program as if it were still halfway between C and a truly object oriented language.
I don't want to be rude, but do you have any idea what you're talking about This is the silliest thing I've heard all day, including an indepth conversation with my 3 year old. It's NOT a kludge, having to write your own typed containers by hand is a kludge. There's no way that templates will allow a C# user to 'use C# as if it was halfway between C and an OO language'. The main problem with C++ is that people CAN use it as if it was C, C# does not suffer from this problem, and generics will not change that.
I have never ever needed a strongly typed collection that wasn't either already provided by the language (except in C++) or easily written
Well, as I said, no one NEEDS these things. All we NEED is a hex editor so we can write binary code directly. But that doesn't mean this is efficent. Type safety does not exist in C# 1.1 unless you write your own collection classes - simple as that.
The very idea that I'm going to write a sequence of instructions and apply them to elements whose type I don't know strongly suggests that either I don't know enough about what I am writing or that whatever is using my code needs to be refactored.
Does this mean that your resume includes all programs that you wrote alone, not as part of a team Because apart from the issue of making code self documenting ( I've got a collection, what should I put in it ), being part of a team means writing code that is hard to use incorrectly, not trusting that everyone knows exactly what all the code does.
It is not at all clear what the "intuitive meaning" of adding TypeX to TypeY or 2 instances of TypeX together is supposed to do.
Assuming that you mean instances of these types, you're again trying to make it all sound more complex than it is. The vast majority of generics users in C# will use them to create containers of type T. And that is a very welcome addition to the language. C# generics don't even have any sort of specialisation, they are very limited compared to c++. I think that anonymous methods is where we'll see innovative coding techniques being born. Generics in C# are too limited to be dangerous to anyone except the terminally stupid.
Adding user defined operator overloading is giving developers too much rope.
Not having it means treating the user like an idiot, and a language that requires various hacks to simulate these useful language features.
The hotshot who gets all excited about templates or operator overloading will go a long way to making maintenance and improvement a nightmare.
I'd be inclined to suggest that the developer who doesn't care about these sort of things is living in the mid 70s. And that once again you cannot judge a language feature by how it can be abused, but by how it can be used. C# does enough to hold our hands compared to c++. It doesn't need to be further held back by failing to offer language features that have proven their worth over many years.
Why on earth would an object oriented language without all the baggage of C++ need templates
Apart from the myraid of other reasons, type safe containers.
Templates are redundant and were one of the many features of C++ tacked on to fix earlier bugs that ended up creating more trouble than they're worth (implicit vs explicit constructors anyone )
Have you read the Design and Evolution of C++ Or are you guessing Templates were added more for creation of type safe containers than anything, but they were made flexible enough that they've found many other uses in C++ that they never will have in C#.
Please let C++ die the slow miserable death its obesity has merited.
C++ will never die, at least not until something at least as powerful with other features to make it more compelling comes along. And if it does, what will your C# compiler be written in, let alone your framework for turning it into something the PC can understand
Preserve the beauty of C#. Just say NO to templates. :)
You will always have this option. I'm just pleased to have the option of using C# as a real language, by seeing more and more good language features being provided. Next we need a standard library as rich as the one in C++.
Dave Rollins
Let's take your thesis and look at the implications. For simplicity sake I will only consider one instance, ArrayList...
ArrayList w/o Generics: Each developer has to make a choice between writing a bunch of repetitive redundant code and having type safety. When you consider the number of developers who will use ArrayList, the effect would be that either MILLIONS of lines of additional code would be written or TENS OF THOUSANDS of applications would be made less stable due to lack of type checking.
ArrayList w/ Generics: Works right out of the box.
Hmm, I think I prefer the latter.
Generics may not solve your problems, but it definitely helps Microsoft and other library developers provide more useful classes.
Charleh
Anyone who takes longer to work out what ArrayList<int> means than MyIntList, or who trusts my hand written code over a templated ArrayList, I don't want them to touch my code, ever. They are definately either too inexperienced or too stupid to be trusted with real world code.
SBurden
If the implementors of the STL that shipped with MSVC++, presumably somewhat more experienced than the average developer, can't (or won't) use templates in a non-obfuscatory way, what hope is there for those of us who have to maintain the code abused by use of templates in C# This is what I mean by "encourages sloppy description". If some of the most advanced developers around, guys who almost certainly have experience creating AND MAINTAINING code, can ship thousands of lines of code with parameter names that might as well be randomly generated, what can we expect from lesser mortals
Their purpose is clear, it's pretty much self documenting.
You must be joking. If they're such descriptive names, why not go whole hoag and name all parameters similarly descriptively
Well, as I said, no one NEEDS these things. All we NEED is a hex editor so we can write binary code directly. But that doesn't mean this is efficent. Type safety does not exist in C# 1.1 unless you write your own collection classes - simple as that.
You're absolutely right. And you've let the cat out of the bag. You do not need to write your own collection 75% of the time. That job is being done by a wonderful bunch of developers at Microsoft. But everyone wants to pretend that they're a 'hardcore' developer by writing their own version of a basic data structure (after all, we spend so much time on lists and data structures in CS classes don't we Isn't that what the 'real coders' do ) instead of using the many suitable alternatives provided.
This would be fine if software only ran in ivory towers at universities. It doesn't. It's everywhere. When you foist your template ridden code, unreadable as possible, off on the poor guy who has to come in and maintain it you're slowing down the entire system. Instead of taking a second to understand what a parameter is storing (like when they have names that MEAN SOMETHING, i.e., they're NOT TEMPLATE PARAMETERS) you force the poor guy to waste an extra 5 minutes figuring out something that should be obvious because the name of the parameter should be meaningful. Maybe you pride yourself on getting that 5minutes down to, say, 2.5minutes. It's still 209 seconds longer than it could be if developers would learn how to program in C# instead of writing C++ for a C# compiler.
Well, as I said, no one NEEDS these things. All we NEED is a hex editor so we can write binary code directly. But that doesn't mean this is efficent. Type safety does not exist in C# 1.1 unless you write your own collection classes - simple as that.
Type safety doesn't exist in C# Then what on earth is being done during verification before JIT compilation to native code What the heck is the compiler doing during compilation into MSIL I think you mean it doesn't exist if you write C++ for the C# compiler. Or if you like to multiply complexity unnecessarily by writing dozens of totally unnecessary custom collections when the ones shipped with the language more than suffice.
We all want type safety. Interfaces are the perfect solution to this problem. The fact that you have to go out of your way to make one will make you think twice before you foist yet another totally unnecessary collection into the software universe. If you are somehow in the business of writing collections then it behooves you to use interfaces to reduce your own maintenance and improvement costs.
Assuming that you mean instances of these types, you're again trying to make it all sound more complex than it is. The vast majority of generics users in C# will use them to create containers of type T. And that is a very welcome addition to the language. C# generics don't even have any sort of specialisation, they are very limited compared to c++. I think that anonymous methods is where we'll see innovative coding techniques being born. Generics in C# are too limited to be dangerous to anyone except the terminally stupid.
Wonderful point. What does the letter T tell me about the elements in the collection again How does one collection of "Type T" elements require behavior different from another collection of "Type T" elements and why doesn't the type name help me out in this regard How would you like it if every method name in a class definition was a single letter, starting with A and moving on down through the alphabet Wouldn't maintenance be so much more fun with things like:
public E A(B _b, C _c, ref out D _d) { ... }
// note1 - fire whoever wrote this method and hire a chimp to replace him
// note2 - fire the person who hired him, and the person who hired the guy who hired him
// note2a - fire anyone related, by blood or marriage, to whoever wrote this method
// note3 - bulldoze any parking spots he ever used before the plague spreads
strewn liberally throughout the code Woah, that's starting to look like an STL implementation! Kinda makes ya wonder why heavy use of templates starts to degenerate into utterly meaningless gibberish like the method above, huh
I'd be inclined to suggest that the developer who doesn't care about these sort of things is living in the mid 70s. And that once again you cannot judge a language feature by how it can be abused, but by how it can be used. C# does enough to hold our hands compared to c++. It doesn't need to be further held back by failing to offer language features that have proven their worth over many years.
Shouldn't the length of a compilation error involving code that uses templates extensively be the hint that the feature is a bad idea If it takes 1500 characters of metatype information (the heck with the error actually helping the reader determine which types are involved ) to indicate a mis-spelled parameter in a language purportedly part of a class of languages intended to make writing software easier for human beings - something is definitely wrong.
C# already has templates. It's called a type definition. Structs, Classes, Delegates all require templating. How else would the compiler know what to instantiate in response to new C++ style templates in C# are redundant no matter how much people have grown attached to them. No matter how much hackery they've kludged together out of this terrible construct.
It is a sad, sad day when a beautiful language gets roped back down into the abyss of the C++ syntax bonanza. Ah well, at least MS added some neat, helpful features to C# 2.0 like Iterators and Anonymous methods. Nullable types also look great.