Is Microsoft abandoning generics?
-
From my perspective, the lack of generics is a massive sideways step in the evolution of programming languages. I see a clear path of evolution of progamming theory : 1. Assembler 2. Procedural (C, Pascal) 3. Object Oriented (C++, Smalltalk, Java, and now C#) 4. Generics (C++ templates, ???) The entire concept of generics is only just starting to get underway - the STL and Containers are just the tip of the iceberg. Whilst OO has moved programming theory foward in leaps and bounds in terms of encapsulation, etc, the "reuse" element has proven to be not as great as first thought. Designing truly resuable classes has proven to be difficult. Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. If the vast majority of programmers are using a language that offers no generic concepts at all, then the entire thory of generics becomes just an academic sideline - one that has little practical application. To me, C# is a step sideways in most regards, and a big step backwards in the area of generics. This cannot be a good thing - but we're stuck with it for the immediate future! Such is the power of a monopoly ...
(I've cut out what I think are the salient points) Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). *** I agree with this mostly *** Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. **** I'm not sure what you mean by "overhead". I think that generics have not spread quickly not because of the C++ implementation - though I think it is fairly complex - but because generics isn't a concept that is widely useful in the way that OO is widely useful, and that generics adds a level of complexity to the programming process. I think simple use of generics is a benefit. I think complex use, though it may make code a bit quicker to write, does not make things easier over the life cycle of the code, simply because generics can make code much tougher to understand and debug. This could be implementation-related, as my experience is with C++ templates, but I don't think it's solely related to implementation. **** C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. **** C# is a component-oriented language; our goal is to make the creation of components simple and straightforward. As for the evolution of programming theory, there are lots of research languages that "push the boundaries", but it takes a while for the good ideas to percolate into mainstream languages. The C# designers are not trying to evolve programming theory; our goal is to develop a productive language, and managing complexity is an important facet of that. And, in the end, we need to come up with a language that our customers will be comfortable with. ****
-
Oh - so it's like Java ? I'm wondering, given how C# is so similar to Java, why it gets marketed as a better C++ instead of a better Java ? I've not used it yet, but every snippet I've seen looks more like Java than C++ to me. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
I think the difference in philosophy is that Java has more of a researchy feel, and C# has more of a practical approach. We have things such as user-defined value types, operator overloading, unsigned types, and a limited version of C-style pointers because such things can be really useful when you need them.
-
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. VC++ 7 is coming soon, and the M$ response to bug reports ( from CUJ/WDJ, where I read them ) is 'known bug, future release'. I don't get why they need to reveal a new lagnauge when they could spend time getting the languages they impliment already right instead. My great fear is that M$ is sick of people pointing out how poorly they do in this area and hope to retire non M$ languages in the next few releases, so no-one can tell them they got it wrong, as they will be *writing* the standard. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. **** It's not a matter of "figuring out how it's done", it's a matter of resources. At the beginning of this product cycle, the C++ team had to choose between making C++ better or developing a way to write .NET code using C++ (known as the Managed Extentions to C++). This was a choice between being part of the .NET world or not, and not having the managed extensions would have made it much much more difficult for people to move to the .NET world. Doing so took a fair amount of resources, and therefore we couldn't make as many improvements to the standard C++ side of the world as we'd like. The Visual C++ .NET (7.0) release does have improved performance, but it doesn't have things like partial template specialization. We do, however, have some new optimization improvements, such as full-program optimization. If you feel strongly about this, you might want to post your views in the microsoft.public.dotnet.languages.vc newsgroup on the Microsoft news server, where you'll encounter PMs who are responsible for the next version (ie the one after this fall's). They know more about our plans than I do. Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here.
-
I agree that we would have preferred to have generics in from the start, but there just wasn't time in the schedule. If we had extra time (has anybody *ever* had extra time while developing a product?) there are other things that we would have put in before adding generics. With the specific implementation we're looking at, generics exist at the IL level, so there's a fair amount of work in the runtime. It's unlikely that generic support would be required as part of the CLS, so they won't be required of all languages. How they show up in all .NET languages is an interesting problem. My *guess* is that the support would be full-fledged in some languages, that other languages might be able to consume generic types but not author them, and that some languages wouldn't be able to use them at all. Being in a multi-language environment means you have to deal with these sort of tradeoffs. Figuring out things like that and how you deal with generics from a class library perspective is one of the reasons that this is a big item. I don't know the exact cost, but I do know that it's pretty substantial.
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
-
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.
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. **** I think that's fairly close to what we're trying to do with C#, though I think it isn't necessarily the complexity of the problem, but how much low-level control and absolute performance is required. That's what C++ is for, and it doesn't make sense for C# to try to do everything C++ can do. ****
-
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. **** It's not a matter of "figuring out how it's done", it's a matter of resources. At the beginning of this product cycle, the C++ team had to choose between making C++ better or developing a way to write .NET code using C++ (known as the Managed Extentions to C++). This was a choice between being part of the .NET world or not, and not having the managed extensions would have made it much much more difficult for people to move to the .NET world. Doing so took a fair amount of resources, and therefore we couldn't make as many improvements to the standard C++ side of the world as we'd like. The Visual C++ .NET (7.0) release does have improved performance, but it doesn't have things like partial template specialization. We do, however, have some new optimization improvements, such as full-program optimization. If you feel strongly about this, you might want to post your views in the microsoft.public.dotnet.languages.vc newsgroup on the Microsoft news server, where you'll encounter PMs who are responsible for the next version (ie the one after this fall's). They know more about our plans than I do. Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here.
This is why developers (Developers, developers, developers!) bitch about Microsoft: you're more concerned with creating your own proprietary architectures than with supporting standards.
-
This is why developers (Developers, developers, developers!) bitch about Microsoft: you're more concerned with creating your own proprietary architectures than with supporting standards.
This is why developers (Developers, developers, developers!) bitch about Microsoft: you're more concerned with creating your own proprietary architectures than with supporting standards. **** I'm usually more concerned about helping my customers solve problems than I am about standards conformance. The whole .NET development environment is a huge improvement in making writing code easier for the majority of my customers, and I think enabling customers with lots of C and C++ code to play in that space is very important. I think that all companies support standards to the extent that it fits with their business goals. It's not that we don't think the C++ standard is important, it's that we had different priorities for this release.
-
This is why developers (Developers, developers, developers!) bitch about Microsoft: you're more concerned with creating your own proprietary architectures than with supporting standards. **** I'm usually more concerned about helping my customers solve problems than I am about standards conformance. The whole .NET development environment is a huge improvement in making writing code easier for the majority of my customers, and I think enabling customers with lots of C and C++ code to play in that space is very important. I think that all companies support standards to the extent that it fits with their business goals. It's not that we don't think the C++ standard is important, it's that we had different priorities for this release.
I think you have pretty wrong picture about the needs of your C++ customers. I don't think that many of us will rush to write managed C++ code (we have C# if we want to do that). On the other side, I REALLY miss the export keyword, and I'm frustrated with the bug with writing wchar_t to wostream (I have reported this bug, but it's not fixed yet). Maybe you should fix the standard C++ first, and then worry about porting to .Net. Anyway, although IMHO .Net is a great thing, my management is not so thrilled with it, and we are not going to write any .Net applications in near future. I vote pro drink X|
-
(I've cut out what I think are the salient points) Generics offers a immediate boost to the reuse concept - in effect, you are telling the compiler to write the details after you give it the broad concept ("Compiler, I want a vector of ints - go do it now, please"). *** I agree with this mostly *** Unfortunately, the only currently widely available implementation of generics theory is C++ templates, and that cares a large complexity burden just in the syntax, if not the concept. I believe that generic programming has not spread quickly precisely because the C++ 'overhead' is too great - the implementation is dragging the theory down. **** I'm not sure what you mean by "overhead". I think that generics have not spread quickly not because of the C++ implementation - though I think it is fairly complex - but because generics isn't a concept that is widely useful in the way that OO is widely useful, and that generics adds a level of complexity to the programming process. I think simple use of generics is a benefit. I think complex use, though it may make code a bit quicker to write, does not make things easier over the life cycle of the code, simply because generics can make code much tougher to understand and debug. This could be implementation-related, as my experience is with C++ templates, but I don't think it's solely related to implementation. **** C# is a new syntax for Objected Oriented programming - it is not a new concept in programming. The lack of generics both limits the language itself, and(and this is my greater concern) the evolution of programming theory itself. **** C# is a component-oriented language; our goal is to make the creation of components simple and straightforward. As for the evolution of programming theory, there are lots of research languages that "push the boundaries", but it takes a while for the good ideas to percolate into mainstream languages. The C# designers are not trying to evolve programming theory; our goal is to develop a productive language, and managing complexity is an important facet of that. And, in the end, we need to come up with a language that our customers will be comfortable with. ****
I'm still happy to hear that Microsoft has listened to developers and is contemplating supporting generics in a future release :-D Regardless if .NET and C# support generics or MI or not, I beleive that .NET represents a signifigant step forward. I have been programming apps in C# for a year now and I have been amazed at the little effort it takes to build a solid application with .NET. Let's focus on the bottom line here: Will .NET make it easier for developers to create great applications? The answer in my opinion is yes.;)
-
This is why developers (Developers, developers, developers!) bitch about Microsoft: you're more concerned with creating your own proprietary architectures than with supporting standards. **** I'm usually more concerned about helping my customers solve problems than I am about standards conformance. The whole .NET development environment is a huge improvement in making writing code easier for the majority of my customers, and I think enabling customers with lots of C and C++ code to play in that space is very important. I think that all companies support standards to the extent that it fits with their business goals. It's not that we don't think the C++ standard is important, it's that we had different priorities for this release.
Standards are for sanity, so that I don't get frustrated trying to make my tools work. When you make products according to standards, you *are* helping me solve my problems. If I have to fight with my tool to make it understand syntax that *should* be working, but I have to figure out a workaround, how is that helping me? CodeGuy http://groups.yahoo.com/group/wtl
-
I think you have pretty wrong picture about the needs of your C++ customers. I don't think that many of us will rush to write managed C++ code (we have C# if we want to do that). On the other side, I REALLY miss the export keyword, and I'm frustrated with the bug with writing wchar_t to wostream (I have reported this bug, but it's not fixed yet). Maybe you should fix the standard C++ first, and then worry about porting to .Net. Anyway, although IMHO .Net is a great thing, my management is not so thrilled with it, and we are not going to write any .Net applications in near future. I vote pro drink X|
These are obviously tough decisions to make. In this case, customers have tons of legacy code that they'd like to be able to use from the .NET world, and without the managed extentions, they're not going to be able to do it. The customers I've been talking to who have been doing .NET development (which is obviously not all C++ developers) consider being able to do this critical to them using .NET
-
Let's face it though - it's hardly surprising that Microsoft are not including generics in C#, if they had figured out how it was done they would have adhered to the full standard in C++. **** It's not a matter of "figuring out how it's done", it's a matter of resources. At the beginning of this product cycle, the C++ team had to choose between making C++ better or developing a way to write .NET code using C++ (known as the Managed Extentions to C++). This was a choice between being part of the .NET world or not, and not having the managed extensions would have made it much much more difficult for people to move to the .NET world. Doing so took a fair amount of resources, and therefore we couldn't make as many improvements to the standard C++ side of the world as we'd like. The Visual C++ .NET (7.0) release does have improved performance, but it doesn't have things like partial template specialization. We do, however, have some new optimization improvements, such as full-program optimization. If you feel strongly about this, you might want to post your views in the microsoft.public.dotnet.languages.vc newsgroup on the Microsoft news server, where you'll encounter PMs who are responsible for the next version (ie the one after this fall's). They know more about our plans than I do. Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here.
Or, alternatively, if there was enough interest, I could try to recruit one, and you could ask questions here. The number of people who responded in the eight odd hours since I logged off and went to bed are probably a testament to the fact that there is a fair degree of concern amongst VC users that the standard seems to be getting ignored in favour of new gadgets. I am constantly disappointed to read about cool things that can be done with templates, with the caveat that VC's implimentation is too poor to support them. For example, I was reading in the Sept 2001 WDJ a review of a book called Modern C++ Design, which apparently includes a library that works under Code Warrior, but due to use of templates ( within the standard ) reports 100's of syntax errors in VC. I'd love to see someone who makes these sorts of decisions here, and I think it's clear from the responses below that I'm not the only one who would like to ask some tough questions about Microsoft's commitment to C++. I'm also interested to know how Microsoft would feel if a third party implimented the C# standard in as ad hoc a manner ? I know we're talking about reasonably esoteric features here, but we're up to release 6, service pack 5, and we're saying no real improvement in version 7. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
-
I'm just being careful that I'm not promising to deliver features in a specific timeframe. If I told you (for example) that we were going to have generics (or any other feature) in the next version and then something changed, you'd be unhappy. I'd rather underpromise at this point. WRT your comment about completeness, while I understand the benefit of having generics, I haven't found the lack of generics to be an obstacle to anything that I've been writing. Can you expand a bit on your stance? Is there a specific situation where you think you'd be too constrained by the language to write your code effectively?
I think you have to look at the strengths of templates to get a clear picture: 1) Type safety. 2) Generalizing algorithms to operate on any data type. You proposed that C# can handle the same things that C++ templates do, in a simpler fashion. From what I see from your example code posted to Christian, C# takes the same route as Java for its container classes: casting. But your code is not quite correct -- to match the equivalent C++ syntax, where the data type is bound to the container and will be caught at runtime, I'd have to write at try/catch handler to deal with a bad cast during a program run: ArrayList ar = new ArrayList(); ar.Add("Hello"); ar.Add("Aloha"); ar.Add("Buenos Dias"); try { for (int i = 0; i < ar.Count; i++) { Console.WriteLine(ar[i]); string s = (string) ar[i]; } } catch (InvalidCastException e) { Console.WriteLine("Illegal cast"); } Compare this to the much safer and shorter C++ version without the need for exception handling (where the data type is bound to an STL list template). Run-time safety is definitely _not_ the same as compile-time safety. This is a big advantage of STL -- I cannot make a mistake in casting that will throw an exception; there's no casting to screw up. Doing a bad cast happens to me a lot in Java programming, when using many different containers with UDTs. Also, another proposal suggests that you can add methods to your own containers easily, but this is just what templates were NOT designed for. The purpose of templates was to separate algorithms from their containers. Template algorithms can operate in a generic way on ANY container in the same fashion. From your example (correct me if I'm wrong), but you can only do simple operations like copy and swap on a C# base Object type. Anything more complex, and you're back to casting or trying to design generic interfaces for some base class container. The only thing I won't argue with you on is iterators, which are the least useful element of STL and probably the most confusing. I wish all STL algorithms assumed that they were to operate on the entire container by default. I hope this provides you with the concrete examples you were looking for. Best regards, CodeGuy http://groups.yahoo.com/group/wtl
-
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.