Is Microsoft abandoning generics?
-
Sidestep my ass! ;) While I use templates, it isn't because I WANT to use them, but because there isn't an alternative. PLEASE don't tell me that you find STL, ATL, or WTL template classes easy to use!!! They aren't. I've been using STL for 3 years, and while I can do some wonderful things with it, they also create quite a bit of confusion....what is "second" when you're using a given iterator?? The compiler knows, but the programmer is a bit fuzzier. I find myself having to look back at my typedefs (needed to keep the template names form getting overly lengthy) a lot....and if I write a class with templates (either a template based class or a function with a template parameter) I have to stick my code in the header whereas all the non-template code can be in the .cpp file....ick! I look at it like this: It seems MS is looking at making 90% of the programmers in the world happier and more efficient....for 10% of the developers C# won't tackle the most complex problems, but since they're in the top 10%, they'll have no problem writting their code in unmanaged C++....where is the tradeoff....or is this really just the sort of thing I hate seeing from my clients -- the desire to have the kitchen sink in everything for no particularly good reason.
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
-
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
I couldn't agree more that templates in C++ are poorly implemented. But at the same time, I also understand the MS stance that they had to start somewhere....and given that everything is derived from a common base object, the absolute need for generics is reduced in C# compared to C++. But again.....I've heard sooooo many silly arguements against C# which boil down to: Why did MS create a new language without my permission....;) Obviously C++ is a very complex, very powerful language. But Java -- the less powerful language -- is being used by more and more people.....so why not create a language which builds on the better aspects of 3 languages?? Afterall, C was built on B.....C++ on C....Java on C++.....it only makes sense. I feel people are throwing the baby out with the bath water with C#.....its still a very new language. Lets use it before we complain about it!
-
So you agree with me! My point is that the THEORY of generic programming is (at the moment) supported by a fairly poor IMPLEMENTATION in the form of C++ templates. The complexity of the basic concept is amplified greatly by the C++ syntax. I have no argument with anyone who wants to discuss the many and varied problems and difficulties in becoming familiar with C++ templates. This has lead to a situation where the only real widespread use of generic programming is containers - the STL being a primary eaample. Yet ATL and WTL demonstrate my basic point better - here are powerful frameworks that offer much greater control and power than MFC, yet are used by most people grudgingly simply because the C++ template syntax and rules are intrinsically complex. Do I want to continue using C++ template for generic programming? Not particularly - like you, I want a better syntax for expressing concepts, an end to typedefs , better documentation, etc. I tolerate ATL/WTL/STL because I have no choice. Do I want generic programming removed from my programming choices? NO! Removing generics from the programming landscape just at the time that the concepts are starting to develop is extremely frustrating. In short, we need to improve generics, not remove them. Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. Had they decided to do that, they'd have got it wrong badly - because there were plenty of rivals, and they were making the move to C++. In the absence of any serious rival for desktop languages in 2001, there is no real market pressure on this current decision, so it will be 'right' by default - and we get 5 more years of 'java-style' programming (just a different flavor of OOP).
Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. ***** Can you tell me what scenarios you'd use generics in that you can't do without them (ie using object) in C#?
-
Eric, being someone who has never been part of a compiler or interpreter developement team, I obviously am no expert, but it seems to me that a computer language is nothing more than a syntax. The compiler interprets the code, and converts it in to a form that the processor can use. My collegue and I came up with this scheme for templates in VB.NET (don't know how MS was planning to do this, if at all in VB, but we liked this syntax):
Public Template <T> Class MyArray
Private m_Array() As T
Private m_nElementCount As Integer=0Public Function Add(newElement As T) As Integer
m_nElementCount+=1
Redim Preserve m_Array(m_nElementCount)
m_Array(m_nElementCount)=newElement
Return m_nElementCount
End Function
End ClassWhich I see as equivilent to:
<template class T>
class MyArray
{
private:
T *m_Array;
int m_nElementCount;public:
int Add(T& newElement)
{
m_nElementCount++;
m_Array=(T *)realloc(m_Array, m_nElementCount * sizeof(T));
m_Array(m_nElementCount)=newElement;
return m_nElementCount;
}
};They're almost identical, except that one is VB.NET, the other is C++(.NET). So why does it matter what language you're using; can't the VB (or C# for those codes) compiler simply use the same algorythms with different key words? Again, I don't know the specifics, so that's why I'm asking. :) Thanks in advance for any insight. Jamie Nordmeyer Portland, Oregon, USA
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
-
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
Ah. I see. Thanks for the reply, Eric. :) Jamie Nordmeyer Portland, Oregon, USA
-
What we're talking about doing for C# isn't a template based approach; it's an approach where generic types exist at the runtime level. I think it's a superior approach for a number of reasons, but implementing it requires both compiler and runtime work.
Forgot to ask; will you be doing such a thing for just C#, or for the CLR (so it's available to all languages)? Thanks again. Jamie Nordmeyer Portland, Oregon, USA
-
Forgot to ask; will you be doing such a thing for just C#, or for the CLR (so it's available to all languages)? Thanks again. Jamie Nordmeyer Portland, Oregon, USA
It will be in the CLR, but it's not clear how much other languages will expose it.
-
It will be in the CLR, but it's not clear how much other languages will expose it.
Well, as a VB programmer, I gaurentee you'll have a lot of people very upset if VB doesn't support some form of generics, when the means to do so exist in the CLR runtime. Myself included. Again it goes back to a matter of syntax; if C++ and C# can handle generics, why on Earth would you leave it out of VB when the syntax, as I imagine it, anyway, is almost identical? Jamie Nordmeyer Portland, Oregon, USA
-
Well, as a VB programmer, I gaurentee you'll have a lot of people very upset if VB doesn't support some form of generics, when the means to do so exist in the CLR runtime. Myself included. Again it goes back to a matter of syntax; if C++ and C# can handle generics, why on Earth would you leave it out of VB when the syntax, as I imagine it, anyway, is almost identical? Jamie Nordmeyer Portland, Oregon, USA
I don't think it's really a matter of syntax; I think it's more a matter of language philosophy. I think the question would be how you could expose generics in VB without adding a lot of complexity. That's really a question for the VB team, however; I'm not that knowledgeable about their users.
-
I don't think it's really a matter of syntax; I think it's more a matter of language philosophy. I think the question would be how you could expose generics in VB without adding a lot of complexity. That's really a question for the VB team, however; I'm not that knowledgeable about their users.
But it's already complex with the cryptic way that API functions are declared, and in VB5 and above, the AddressOf operator. Generics couldn't complicate things too much more. But, that's for the VB team. ;) Jamie Nordmeyer Portland, Oregon, USA
-
Microsoft created C# - in doing so, they had to make choices. They decided that generics was not as important as other features. I regret that decision very much - to me, it sounds a little like deciding to make an "improved C compiler" rather than a "new fangled C++ compiler" back in 1989. ***** Can you tell me what scenarios you'd use generics in that you can't do without them (ie using object) in C#?
Eric, I can't give you an exact scenario of what I can do in C++ that I can't do in C#, because I haven't used C# yet. So why do I comment on a language I haven't used ? Well, from what I have read C# as some real advantages (I personally am a 'believer' in garbage collection, for example), but it has removed what I consider to be THE most important development in software theory in the last 5years - generics. I can give you a sample of what I am starting to do with templates. C# may be able to do this some other way, so this may not stand as a perfect example of the differences - however, I still believe that my use and understanding of generics(templates) is only just beginning - containers are the obvious first example, but generica can go much further. I needde to develop a persistence system for reading/writing C++ objects to disk. I wanted this to be 'seemless', and to handle both objects, containers of objects, and containers of pointers of objects. In the later case, a container of objectws may not all be of the same type - the container may conatiner pointers to base objects, or to any number of derived class objects. To make such containers 'type safe' I needed to be able to defined aleternative methods of 'copying' a container. For utility reasons I needed to write a 'find' function that searches a special variation of containers and finds items that match a given string. In some instances this search is case sensitive, in some cases it is not. So I had a number of varying requirements - XML IO, string matching, containers of pointers, base/derived construction and copying. I have written a set of templates that encompasses all of these requirements - any programmer can now simply 'request' the type of the functionality required of his objects/containers by simply inherting from template classes, or sending his own class into a template. Is it complex ? yes. Is the syntax frightening? Yes (well, typedefs REALLY help this a lot). Does it work well ? Yes. I can now implement any number of variations on these themes, with just a single line of code, and can extend this system at any time (for instance, if I need a new type of string matching - say Asian language support) I roll up a new 'string matching traits' template, and it instantly 'fits' with all the other classes and templates. I regret the syntax and complexity that C++ templates forces on me, but the end result is SO powerful it amazing. "Modern C++ Design" is the book that best demonstrates these new concepts. The
-
I couldn't agree more that templates in C++ are poorly implemented. But at the same time, I also understand the MS stance that they had to start somewhere....and given that everything is derived from a common base object, the absolute need for generics is reduced in C# compared to C++. But again.....I've heard sooooo many silly arguements against C# which boil down to: Why did MS create a new language without my permission....;) Obviously C++ is a very complex, very powerful language. But Java -- the less powerful language -- is being used by more and more people.....so why not create a language which builds on the better aspects of 3 languages?? Afterall, C was built on B.....C++ on C....Java on C++.....it only makes sense. I feel people are throwing the baby out with the bath water with C#.....its still a very new language. Lets use it before we complain about it!
I hate to boil things down to a 'single issue', but my one and only (strong) issue with C# is generics. In many ways C# sounds like an improvement over C++. I also liked a lot of Java concepts (initially). The only point I am making here that generics are far more important than just container implementations. There's a whole new level of programming (type safe, efficient, flexible) hiding in the C++ syntax, and Java and C# are locking us out of it entirely. What we need is a language where generics are a primarly feature, not an add on (as they are in C++, and will be in Java and C# (perhaps - it remains to be seen whether such promises ever really see the light of day, and in what form)). I accept the reality that we don't have that, and will not have that in the forseeable future. I am just expressing a little frustration that the first large scale, widely available language in the last 6 years has chosen to ignore a major advance in programming theory, simply because generics are difficult to implement, and are assumed to be about 'containers'. Very short sighted, very wrong.
-
I hate to boil things down to a 'single issue', but my one and only (strong) issue with C# is generics. In many ways C# sounds like an improvement over C++. I also liked a lot of Java concepts (initially). The only point I am making here that generics are far more important than just container implementations. There's a whole new level of programming (type safe, efficient, flexible) hiding in the C++ syntax, and Java and C# are locking us out of it entirely. What we need is a language where generics are a primarly feature, not an add on (as they are in C++, and will be in Java and C# (perhaps - it remains to be seen whether such promises ever really see the light of day, and in what form)). I accept the reality that we don't have that, and will not have that in the forseeable future. I am just expressing a little frustration that the first large scale, widely available language in the last 6 years has chosen to ignore a major advance in programming theory, simply because generics are difficult to implement, and are assumed to be about 'containers'. Very short sighted, very wrong.
I don't know if I'd say it was short sighted to choose to implement it later due to it being difficult....a lot of my development takes exactly that route....and often by doing that, I give myself more time to think about the problem and come up with a better solution. The way C++ implements templates is a curse on mankind. So if MS went ahead and added generics that were basicaly the same as what C++ offers via templates, we really won't be moving forward. Perhaps with a couple million people writing code in C#, a better way will emerge based on actual developer input rather than the compiler teams assumtions about how people are going to work. I'm going to miss container classes....I'm going to miss algorithms.....but I suspect that there is something which will replace -- after all, I didn't even realize I needed them until 4 years ago! So lets all just relax and take a wait-and-see attitude.
-
Eric, I can't give you an exact scenario of what I can do in C++ that I can't do in C#, because I haven't used C# yet. So why do I comment on a language I haven't used ? Well, from what I have read C# as some real advantages (I personally am a 'believer' in garbage collection, for example), but it has removed what I consider to be THE most important development in software theory in the last 5years - generics. I can give you a sample of what I am starting to do with templates. C# may be able to do this some other way, so this may not stand as a perfect example of the differences - however, I still believe that my use and understanding of generics(templates) is only just beginning - containers are the obvious first example, but generica can go much further. I needde to develop a persistence system for reading/writing C++ objects to disk. I wanted this to be 'seemless', and to handle both objects, containers of objects, and containers of pointers of objects. In the later case, a container of objectws may not all be of the same type - the container may conatiner pointers to base objects, or to any number of derived class objects. To make such containers 'type safe' I needed to be able to defined aleternative methods of 'copying' a container. For utility reasons I needed to write a 'find' function that searches a special variation of containers and finds items that match a given string. In some instances this search is case sensitive, in some cases it is not. So I had a number of varying requirements - XML IO, string matching, containers of pointers, base/derived construction and copying. I have written a set of templates that encompasses all of these requirements - any programmer can now simply 'request' the type of the functionality required of his objects/containers by simply inherting from template classes, or sending his own class into a template. Is it complex ? yes. Is the syntax frightening? Yes (well, typedefs REALLY help this a lot). Does it work well ? Yes. I can now implement any number of variations on these themes, with just a single line of code, and can extend this system at any time (for instance, if I need a new type of string matching - say Asian language support) I roll up a new 'string matching traits' template, and it instantly 'fits' with all the other classes and templates. I regret the syntax and complexity that C++ templates forces on me, but the end result is SO powerful it amazing. "Modern C++ Design" is the book that best demonstrates these new concepts. The
Thanks for the example. In my earlier posts, I neglected to point out that C# does support a variant of generic programming; since everything is be derived from the type "object", an object reference can point to any type in the type system. This means you can write a collection that stores any type, and you can write object persistance code (though serialization is built into the framework, so you don't need to). This is type safe, but it isn't compile-time typesafe; that would be one of the benefits of a real generics implementation.