Talk:Generic programming

Dynamically-typed Languages

All the examples (except possibly Lisp) seem to be of strongly-typed languages. From my understanding of C++ templates and Java generics, they're mainly needed because there's no 'Object' class that would allow a parameter to be of any type. Can someone write something in the introduction to confirm or refute this assertion of mine? Or to clear up my confusion. Thanks! --Booch 22:22, 14 December 2006 (UTC)

This confuses parametric polymorphism with generic programming -- no, templates are not equivalent to having an 'Object' class: C++ templates are Turing-complete, and their pattern-matching facilities allow ad-hoc overloading. --Someone

C++ templates bring duck-typing at compile-time. Languages which use dynamic duck-typing have therefore no need for such a facility. --140.77.129.158 (talk) 08:50, 3 April 2008 (UTC)

C++ Templates do not equal static duck-typing. If a function does not call a method due to some conditional statement then the method doesn't have to exist on the dynamically, duck-typed object. A statically resolved template would have to ensure the object had the method in all cases. --Paddy (talk) 15:52, 3 April 2008 (UTC)

Is this template metaprogramming?

I think what the current article describes is NOT template metaprogramming. see [1]. -- ChristianWBrock

No, it is not. I moved that here. While it has a really good point, it is not written in the way of encyclopedia.

The standard example for the desirability of templates is the problem of implementing a type-safe data container, like a stack or a dictionary. The semantics of stack (whatever goes last in goes first out) is defined irrespective of the type of its elements, but the application programmer would normally like to restrict what goes in a particular stack (just as they restrict what can be assigned to a particular variable). That makes a generic implementation (by the library programmer, who cannot know all the applications built on top of their library) problematic. The unwanted dependency from library to application can be broken by abstracting the type of the stack's elements. The library programmer can then write a stack template, which is instantiated by the application programmer for the type they want to use. The concrete implementation of this concept (not just for stacks and dictionaries, but for many other containers, and also for algorithms operating on (abstractions of) those containers) is called STL and is part of the standard C++ library.

The "meta" in template metaprogramming distinguishes between an algorithm specifying a mapping from input to output data (and programming meaning writing down the algorithm) and a meta-algorithm - a mapping from types to algorithms (i.e. the pop() template method of a stack template maps int to a pop() for a stack of ints) in the process of template instantiation. Instantiation is not necessarily trivial - template metaprogramming techniques rely heavily on recursion and the resulting code is generally considered confusing and difficult to read.

-- Taku 04:51 Mar 18, 2003 (UTC)

Agreed that what this article describes is *not* generic programming, which entails deriving abstract concepts with their axioms from a series of concrete models of those axioms, but rather describes programming with templates. Any description of generic programming should include a reference to the (co)-inventor of generic programming, Alexander Stepanov (e.g. see http://www.stlport.org/resources/StepanovUSA.html and http://www.stepanovpapers.com/ and the other references in the Stepanov wikipedia entry). Brianbjparker (talk) 07:31, 18 March 2008 (UTC)

Adding all the "Generic programming in Haskell" chapter

I've added a whole chapter about generic programming techniques in Haskell, since there is a lot of research in that area and I was surprised not to find anything mentioned here. It's my first contribution to Wikipedia, so I am sorry for any mistakes in the style. I'd appreciate if someone was to check the references, since I am not sure they are in the best way they could.

-- Dreixel 15:02 Dec 9, 2004

Somebody should have a look at the paper by Garcia, et al.; see http://citeseer.ist.psu.edu/garcia03comparative.html -- it provides a comparison of generic programming in languages like SML, Haskell, C++, Eiffel, etc. If somebody reads it, it should help clarify quite a bit of the discussion.

Lisp (CLOS)

Can someone competent (that excludes me) say something about generic programming in common lisp? MartinL25

Might do, instead, to merge this C++-centric article with Generic function, Multiple dispatch, and Multimethods, with reference to CLOS. --FOo 21:25, 12 Dec 2004 (UTC)

Why even provide code for specific languages at all? The majority of this article reads like a tutorial on C++ template programming. Pseudo code could have done the job better. 217.43.59.160 19:59, 30 November 2005 (UTC)

Specific code is good, because it concisely demonstrates the issue. If anything, more language-specific examples are desirable, especially from a broad spectrum of notations. 24.86.211.70 08:22, 13 February 2006 (UTC)

An article can easily be overwhelmed with near-equivalent examples in lots of languages. A difficulty of articles about programming concepts is that a person really does need experience in a few different languages to understand the more advanced concepts. So we need to use examples in various languages. However, the more languages we use in the article, the less likely that any given reader will be able to understand it all. --FOo 10:33, 13 February 2006 (UTC)

I agree as well that articles can easily become diluted with too many me-too programming examples. But it is good to show specific language examples for all but the most general of topics. Usually any moderately-popular language that brings something unique to the topic is worthy of inclusion. For this topic in particular certain specific languages also are worthy of discussion because of their historical relation to the topic (in addition to just language features). Of those I think Ada programming language is historically important as one of the first major languages with generic features part of the core language (and probably deserves even more coverage here). And C++ is also important because it both popularized generic programming, as well as introducing a very rich templating-style system that matches exactly this article's topic. If other languages have either historical significance to this topic or illustrate a substantially different approach to generic programming then please include it; but if it's just a me-too, then I'd rather not see much except perhaps a short mention. -- Dmeranda 05:34, 2 April 2006 (UTC)

Generic programming in Haskell

The "Generic programming in Haskell" section doesn't belong here. I would suggest creating an article on the Haskell programming language and moving it there. Leave a brief description of Generic programming in Haskell and make a link to the Haskell article. -- new299 17:41, 22 March 2006 (UTC)

Yes, there should be some separation between the two meanings of "generic". There *are* similarities between the two communities, but the aims and techniques differ rather substantially between the C++- and Haskell-styles of generic programming. However, Haskell-style generic programming (à la Generic Haskell) is quite a separate topic from the Haskell language just as the Ada/C++-style generic programming is separate from those languages.

Also, Haskell fully supports parametric polymorphism but the way this is written, the impression is given that it does not. Itsbruce (talk) 14:41, 16 October 2017 (UTC)

Cleanup advert tag

Unless someone explains the cleanup {{advert}} tag soon, I'm going to remove it. Lambiam^Talk 22:45, 1 April 2006 (UTC)

I'm not responsible for the tag so I don't know the original complaint, but I think I tend to agree that the Haskell section as written has problems. There are POV tone problems in a few places, for example the introductory sentence begins "In Haskell in particular,...". There's no reason why Haskell is particular; it sounds a bit of language chauvinism (some of the newer Java additions also have I think some similar tone problems). Those kinds of problems can be easily fixed without substantial changes. Also there's a good bit of feature listing, of which I'm not sure is necessary. Some things, although great for an article about Haskell, are in my opinion not really good examples of generic programming in the scope of this article--such as the deriving keyword examples; other languages have similar code generation capabilities yet they aren't discussed in this article. The most advertising-like parts though are the subsections near the end. The Generics for the masses section for instance provides no useful information or insights about generic programming, but is mostly just a book-sleeve-style advertisement for the book listed in the references section. Perhaps I'll give a it a shot at editing and see if I can improve it. -- Dmeranda 05:17, 2 April 2006 (UTC)

One general problem with the article is the very specific technique given in the introduction as the "definition", instead of being an instance of generic programming. A better starting point might be the formulation from this synopsis for the proceeding of this conference of Generic Programming[2]:

Generic programming is about making programmes more adaptable by making them more general. Generic programmes often embody non-traditional kinds of polymorphism; ordinary programmes are obtained from them by suitably instantiating their parameters. In contrast with normal programmes, the parameters of a generic programme are often quite rich in structure; for example, they may be other programmes, types or type constructors, class hierarchies, or even programming paradigms. Generic programming techniques have always been of interest, both to practitioners and to theoreticians, but generic programming techniques as a specific focus of research in the functional and object-oriented programming language communities is a contemporary phenomenon.

A better organization might then be, after generalities introducing some notions and terminology, to have sections like "GP in OO languages" and "GP in functional languages". Much of the use of generics in OO languages seems to be covered by polymorphism in functional languages. A complication is that some things like "Scrap your boilerplate" and "Generics for the masses" are about approaches, but require certain language-specific features offered by Haskell but not ML. Lambiam^Talk 10:40, 2 April 2006 (UTC)

Yes, that sounds good. I think the article was written more from the historical evolution of the term "generic programming". If it has now evolved to be, well, more generic, especially when documented as such by your reference, then the article should be expanded. Separated into OO and functional is in this case I think a rather nice division because the generic techniques are so different. I would still like to preserve some of the history though, so starting with things like Ada (after a basic introduction) make sense. And some of the more edge cases in Haskell should be trimmed or moved to a Haskell-specific article. -- Dmeranda 16:08, 2 April 2006 (UTC)

If you have the time and inclination, you're probably better qualified to give the re-organization a first shot. For the historical sense it is important to realize that one thing driving the evolution of programming languages is the desire for better abstraction mechanisms, and absorbing more genericity into the core of the languages is one way of achieving this. So it is not a coincidence that the development of "generic programming" is typically on the edge of existing languages. Lambiam^Talk 22:45, 2 April 2006 (UTC)

"There's no reason why Haskell is particular; it sounds a bit of language chauvinism" I think I should respond that. Generics / Templates are a useful featured used occasionally by Java and C++ programmers. Haskell whole type system is based on type classes, which are similar to Java / C++ generics/templates. Not using "generics" in Haskell would require effort and I can't think of a single example of a Haskell program over 20 lines that doesn't use them. This statement would be like "Perl in particular for regexes", or "TeX in particular for calls to Metafont" ... The real problem is that there while generics are similar to type classes I'm not sure they really are the same thing, "in generic programming values depend on types whereas in a dependent type system types depend on values".

Unfortunately this gets more confusing because Haskell has a notion of generic but the focus is on another aspect of generics in Java/C++ than what programmers in those languages are likely to think of (classes of definitions being spread incorporates a different modules). So doing what is being suggested (breaking the articles up) is likely to make things worse since the same words are going to end up meaning different stuff depending on where the "holes" are in the various languages.

So in short: 1) The comment is either false or fully justified, depending on how you want to define generics in a very abstract sense :-) 2) Haskell's type classes are a useful extreme implementation of generics. Seeing a more powerful version of generics may make it easier for Java programmers to see why they would want them at all. 3) You have to decide who the audience is for this article. The current article is written for a mainstream audience. An article on Haskell, for Haskell programmers, using the term generics needs to use the term to mean other that what it is meant in this article (which is directed at Java / C++) programmers.

Hope this helps. Jbolden1517 03:41, 20 April 2006 (UTC)

It is insightful but not very concrete as to how to proceed. I should hope our articles have something to offer to both the general audience and the specialist. See also Wikipedia:Manual of Style (mathematics)#Suggested structure of a mathematics article and for example how the article Continuous function is built up. Even assuming we reach a consensus here-and-now on this talk page, the actual "consensus" is reached by the ants crawling over the pages, collectively computing a fixed point (or not). So a good aim also considers stability. Eventually we may have article spinoffs, but in general it's a good idea to start with keeping things on one page and only spin off when it becomes unwieldy. So, question, do you agree with the specific proposal put forward above in the paragraph starting "A better organization might then be", or do you have an alternative proposal? Lambiam^Talk 09:45, 20 April 2006 (UTC)

Actually I'm arguing for something very similar to what was done with continuity. The main page is aimed squarely at the calculus student. The next level of definition (continuity in a topological space) is linked to but not included [[Continuous function (topology)]. By a mathematical standard the topological definition is the "better" definition and the article should focus on that with an aside that "in any metric space the following epsilon-delta definition can be used" and another aside "in any map to a complete toplogical space a continuous function maps a Cauchy sequence to a convergent sequence" The problem with that approach is that its only useful for a reader who already understands continuity fairly well, which is to say not in general a calculus student. So instead the main article becomes explicitly instructional with another article that discusses the topic for someone who already has some background.

Similarly I think the article on main generics should be aimed at the Java/C++ programmer not the Haskell programmer. There should be a link to another page which discusses generics in Haskell. The material on this page dealing with Haskell is important because it can be instructional and once the Java/C++ reader is assumed it would be easy to clean this up a bit to make things even clearer. I don't know what generics mean in ML so I don't have anything intelligent to say about generics in ML and how that should be treated.

Anyway my comment was mainly aimed at Dmeranda's comment and meant as informational. Jbolden1517 12:32, 20 April 2006 (UTC)

I'm not so sure about splitting out the Haskell stuff yet; I'd like to see an attempted cleanup here first. But I only have a weak opinion on that now. I certainly think that it's best to keep the most likely subject up top (C++, etc), and then put the more technical later (Haskell, etc.). I do fully understand that "generic" programming in languages like Haskell is mostly the normal way of doing things (I have after all programmed in both C++ and Haskell). But it's also why I think that material should follow...it's just not thought of as "generic" programming, but instead just "programming". Whereas with C++, the introduction of the template system really helped popularize generic programming (at least from point of view of the term "generic"). However, I'd even like to see more. I still think that Ada is worthy of much more mention, as it really was responsible for a lot of pioneering work in generics. And I wouldn't even be opposed to allowing the article to grow beyond Haskell into some type theory too...there's room for all I think. But in the short term though, I think the Haskell section (while certainly worthy of inclusion), needs some serious editing work to get it more NPOV and more encyclopedic. And maybe it's even worth pulling some of the material on this talk page into the article, perhaps explaining why "generic programming" in Haskell is so important or different. -- Dmeranda 04:44, 24 April 2006 (UTC)

I have big problems with the way the Haskell chapter is written. Of the five "approaches" presented, three are not actually Haskell but proposed or experimental extensions to Haskell (one of them is supported by the most popular Haskell compiler, but that's still borderline); the other two should be merged and comprise what should properly be called a chapter on Haskell. Furthermore, the three extensions to Haskell are somewhat academic in nature, so I suspect that their purpose in existence is not so much to improve the Haskell programming language as to expand the repertoire of powerful genericity constructs available to language designers. (This is particularly true of the so-called "Scrap your boilerplate" approach.) The fact that the research on these constructs was conducted in the setting of Haskell is, I suspect, somewhat incidental. The most appropriate way to handle them in my opinion is to split them off into a separate chapter on recent theoretical developments and clean up the citations and references so that their nature is clear. Cjoev 18:36, 24 April 2006 (UTC)

I agree with everything you say about what's wrong with the Haskell section, and would appreciate if you or another Haskell guru attempts a rewrite. However I still disagree that we should break up the page, at least now, to insure we don't accidentally do a content fork. If the Haskell information is academic in nature or perhaps not pure Haskell, that to me still doesn't warrant a different article. It's still potentially useful information about generic programming, even if it's not mainstream. But it should definitely be discussed in the text so as not to be misleading. My recommendation is to rewrite it first until it looks better, and only then decide if what's left still fits this article or should be forked out. (Thanks btw for your cleanup of the history/intro, it's looking better) -- Dmeranda 19:22, 24 April 2006 (UTC)

Well, I'm not exactly a Haskell guru myself, but I can give it a try. (Don't hold your breath, I'm kind of busy these days.) I wasn't suggesting that the not-really-Haskell stuff should go in a different article, just in a different section of this article, separate from the information about real Haskell and labeled in a more truthful way. Cjoev 20:12, 24 April 2006 (UTC)

I've tried to do something like what we've discussed. There is now a section on Haskell in what I hope is a more neutral tone, and I've relabeled the other three things as "recent developments", deemphasizing their Haskell bias as much as I can. What I haven't been able to do is improve the quality of the material on PolyP, Generic Haskell and SYB, because I'm not familiar enough with them. Cjoev 22:19, 4 May 2006 (UTC)

Generics in Java

After a full section on how templates work in C++, Java only gets "See Generics In Java", with a link to an external link. Would it be useful to go into some details on how generics function in Java, describing such concepts as type erasure and wildcard type parameters? —Matthew0028 04:57, 23 April 2006 (UTC)

Sure, contribute if you can! I have to admit I'm not a great resource for Java stuff. However try not to get caught up in comparing how much space each language gets, as long as what's written contributes useful information to the subject. Since Java is a newcomer to generic programming, I think the most important contributions to this article I think would be to discuss what kinds of unique concepts or new things Java might bring to the subject of generic programming that didn't come before or that don't have obvious parallels in other languages. Java specifics which might not be very notable here, may be on some other Java article, so you could also write a summary here and link to more information you write elsewhere. To save some work, it might be good to search around in some of the Java corners of Wikipedia and see if some generics information has already been written; and then either link to it or perhaps include some of it's information here. -- Dmeranda 05:06, 24 April 2006 (UTC)

As a newcomer to this discussion, I second the main idea of Dmeranda's response. Details on Java generics, especially the ways in which they differ from C++ templates (for instance, generic Java classes are typechecked once and for all when they are defined, rather than each time they are instantiated as I have heard C++ templates are -- and of course syntactic differences like wildcards should be mentioned too) would strengthen this article. I disagree with some of what Dmeranda says both here and in an earlier thread regarding the balance between languages represented. I think there is probably a misconception among some readers that languages other than C++ either don't support generic programming or support it in a lame attempt to copy C++. Any bias toward C++ as the gold standard of generic programming is something a fair and neutral article should not perpetuate. What I would love to see here is a thorough discussion of generic programming in some kind of language-neutral pseudocode, supported by concrete details about specific languages, rather than an article about C++ with other languages added as an afterthought (which is what it seems to be now) or a monster article that rehashes the same ideas, perhaps inconsistently, in many different languages. -- Cjoev 06:03, 24 April 2006 (UTC)

Added initial Java section. I'll be the first to admit that it's probably a bit rough, too verbose, and possibly goes into too much and/or too little detail. But it's a start. —Matthew0028 13:17, 24 April 2006 (UTC)

Thanks Matthew. Your addition actually looks pretty good to me. There may be a few small things I can correct, but then maybe you or any others can also refine it even more. If you haven't already, you may want to review some of the rest of the Java corpus and see where opportunities exist to wikify/cross-link this content as appropriate. As for the alleged C++ bias, we do need to be careful when comparisons are made between languages (as a small example the other way, it's not always true that C++ templates result in new code for each instantiation). However size of the subsections alone doesn't necessarily indicate bias. I've seen way too many other articles spoiled by turning into a long "me-too" style list where everybody had to add their favorite obscure language even when it contributes little value. For this article C++ is important because 1) it really was perhaps the one language which popularlized "generic programming" in the mainstream, 2) it's large library is almost entirely built upon and dependent on generic programming techniques, and 3) templates are very rich and quite unlike how a lot of other languages work, and so just takes a certain amount of exposition to explain. There are lots of other articles where C++ probably deserves little or no mention, not because the language may not support some feature, but just because it has nothing interesting or unique to add to the subject. But if you see any actual bias, please fix it. Regardless, I welcome the bit of Java stuff here. Even us "C++ guys" would like to be able to learn how other languages may have different approaches, so I'm a reader too. I'd still like to see more about Ada (or even CLU) here for the same reason. -- Dmeranda 14:48, 24 April 2006 (UTC)

An anonymous editor added the following somewhat dense explanation of a workaround for one of the "Limitations" of Java generics. I've rephrased at the expense of some detail:

(There are some ways around this, like saving class information Class<T> classType = (Class<T>)passed_in_T_object.getClass();, and then passing that to an array initializer from java.lang.reflect.Array in E[] newE = (E[]) Array.newInstance(classType, size). This is not an ideal solution, and you will have to use the @SuppressWarnings("unchecked") in order to avoid compiler/other complaints.)

Retaining type parameters at runtime
Class parametres are stored in private genericInfo field defined in Class object:

   private transient ClassRepository genericInfo;

and available as follows:

public class Test2 {
   static class A extends ArrayList<String> {};
   public static void main(String[] args) {
       A a = new A();
       Object x = a;
       ((Collection)x).add(new Byte((byte) 1));
       System.out.println(x.getClass().getGenericSuperclass());
       System.out.println("We have a list parametrized with: " +
               ((ParameterizedType)x.getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
   }
}

Output:

java.util.ArrayList<java.lang.String>
We have a list parametrized with: class java.lang.String

D

The section on D reads as quite self-slanted and non-POV --especially the introduction-- and biased against C++, which it apparently compares itself against. Also, the "max" example includes additional code --static type testing-- not in the C++ examples (to which it is a comparison). Such type testing is equally possible in C++, though with much more extensive code constructs using templated metaprogramming (See Alexandrescu's Modern C++ Design), but the point of this article is not showing the syntactic superiority of one's language of choise but to as succintly as possible outline generic programming, something to which, again, the static typecasting is advertisment fluff. I removed it and reformatted the code to the same indentation style as the other examples and the C++ code to which it refers. Mikademus 07:18, 19 July 2006 (UTC)

I think it could be nice to have a D section, however as it stands I see two problems: 1) the language used needs some editing to make it more neutral as well as just better prose and grammar (this is easy to fix), and 2) it doesn't tell the reader much of anything new about generic programming (this needs a subject expert). The opening says that D was designed to improve upon C++'s templates and therefore provides better mechanisms, but then these claimed improvements are not shown. Just minor differences in syntax are not really noteworthy; unless there is a reason that makes it better, in which case it needs to be discussed. Not being a D programmer myself, I am confused by the two examples of max() and factorial()---is the keyword template required or not? Futhermore the discussion of the so-called static-if, while quite interesting, sounds to me as if it should be discussed on the Template metaprogramming article rather than this one. Also the "Implicit Template Property" subsection is very confusing for non-D programmers and probably too short to warrant a whole subsection. Are there any D experts who can improve this section?--Dmeranda 16:44, 19 July 2006 (UTC)

To answer the question: the 'template' keyword can be elided for function and class templates. The factorial example is just a templated const int, and so the keyword is required. I have written on this topic for Everything2 [3], which of course does not have a NPOV policy. I would be willing to re-write the more, ah, spirited sections if anyone thinks the writeup has merit for Wikipedia. --KirkMcDonald 17:46, 19 July 2006 (UTC)

Yes please, Be bold. Just be sure that you either rewrite, or if copying you have the appropriate rights to include here under WP copyright terms. If possible please try to keep focus on generic programming. --Dmeranda 18:07, 19 July 2006 (UTC)

I agree with Dmeranda, who summaries the arguments very concisively and insightfully: the D section is basically an obliquely agressive case of D's syntactic superiority over C++. As such it contributes nothing to the discussion or understanding of generic programming, while the C++ section is quite carefully tailored to the topic of the article. Unless something of true significance to the topic of generic programming can be obtained by discussing D --or other languages-- I would move the entire D discussion to the language's own article and strike it from here altoghether (or trim it down radically and position it under the "Generic programming facilities in other languages" header). Perhaps a drastic, though bold, suggestion, but as it is the header doesn't really contribute anything to the topic. Speaking of the other languages: Ada, C++ and Java certainly deserve treatment since they represent significant takes on genricism, and I would personally like to see Objective-C mentioned. Mikademus 20:34, 19 July 2006 (UTC)

I have attempted to tone down the D section and focus on the actual additions D makes to the realm of generic programming, viz. easier to parse syntax than C++, static-if, and alias parameters. Aside from these, D's templates are (mostly) the same as C++'s. --KirkMcDonald 00:45, 21 July 2006 (UTC)

Thanks for the rewrite Kirk. I believe the content of the D section is now appropriate and adds useful information to the topic in a neutral way. Of course it still may be possible to improve the content even further, but I'm going to remove the POV neutrality tag; if anybody disagrees you can add it back and explain what problems still exist.--Dmeranda 03:48, 21 July 2006 (UTC)

The section certainly is much improved now. I still feel is is somewhat redundant since it is basically a commentary on how C++'s somewhat unwieldy syntax can be improved, The first paragraphs detail the syntax of templates in D --how they differ from and improve on that in C++-- which is not very relevant to the topic. Further, I'm uncertain as to how the "static if" section (though interesting) contributes to the understanding of generical programming. D's "alias parameters" seems relevant but are currently only described as nice ways of interfacing with C. Instead, I would scratch the entire interfacing-with-C discussion and rewrite the section to treat how alias parameters, which are important in other laguages with generic capabilities and will be part of the C++0x specs, contribute to generic programming. However, the neutrality is in an altoghether different league now compared to before. But I would like to emphasise again that the section still reads as redundant since it doesn't contribute to the discussion of generic programming, or if it does, it is too subtle for us (or me, at least) not well versed in the D language. Mikademus 16:46, 21 July 2006 (UTC)

As far as syntax, I agree it is not important to this article, except where it is needed for exposition purposes (e.g., to make the examples understandable for non-D-programmers). I think some mention of the unusual a!(b) lexicon is needed; the question is if the paragraph discussing the syntax can be made briefer without making the article harder to read? As far as the static-if construct, I now see its value as essentially a completely different approach to doing template specialization. However the example factorial code certainly does not use it for that purpose and so doesn't support this article (it probably belongs on the template metaprogramming article instead). The alias parameters seem very relevent to me, but I wish they were described a little better. How do they relate to macros for instance, or α-conversion (free and bound variables), or even Python decorators? I don't know if perhaps a better example could be created that's not too overwhelming? Perhaps the D experts can take this feedback from us non-D programmers and make it even better.--Dmeranda 18:17, 21 July 2006 (UTC)

That is exactly right: I kept the description of a!(b) to make the examples understandable. Static-if has numerous other uses, of course, many of which revolve around D's highly powerful "is" expression. In its simplest form, it is a direct test for situations SFINAE would otherwise be used for. It can also test whether one type is the same as another type. It is also trivial to derive the return type of a function type using "is", something that is quite difficult in C++. However, to point these out in the article would essentially be making the same point again. (That static-if is a different approach to template specialization.) I chose the factorial example because the equivalent C++ template must make use of (if I remember correctly) three templates and much more verbose code. It is, in my mind, the most concise example of the technique, though it is probably less illuminating without the equivalent C++ template to compare it to. Placing that template in the article begins to get off-topic again, I think. As for alias parameters, the uses for them are so vast that it is difficult to pick a concise and descripive example. I chose the C interfacing example because it was the last thing I happened to use them for. A better example is more than welcome. --KirkMcDonald 19:22, 21 July 2006 (UTC)

Ok, then the section should be condensed to discuss the aspects in particular where D contributes to generic programming. If Dmeranda is correct in that "static if" is a completely other take on generics then that point need to be discussed and exemplified, and I'm not certain if the factorial example is an adequate illustration of this since I failed to get that point. Also, the alias parameters seems to be of relevance and a discussion about these should be added. Static derival of return types risks venturing into pure language comparisons since C++0x will be equipped with a of_type (forgot what it is to be named) static operator and other languages have this facility too. Thus in short, the section should be condensed, sharpened to drive the relevant points home, and a better example should be found (invented?). I am doing a bold edit to test your reaction: since the "D templates" section is in all a commentary on the "C++ templates" section, I'm moving it to that section as a corollary. It makes more sense like tat the way it is written atm. Feel free to revert if you disapprove of this. Mikademus 10:55, 22 July 2006 (UTC)

Does there have to be an exclamation point in factorial!(n-1)? Does it make the call static or was it a mistake? — Preceding unsigned comment added by 99.240.99.150 (talk) 23:00, 29 May 2011 (UTC)

Introduction

It seems to me that the introduction does not reflect the rest of the article. The introduction, for example, says that "The type class mechanism of Haskell supports generic programming", which is true, but does not reflect other ways of doing generic programming (e.g., http://www.informatik.uni-bonn.de/~ralf/publications/ComparingGP.pdf). Maybe it would be better to talk about different views on generic programming in the introduction? Another paper I could recommend: http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf

If I make a suggestion, do I have to write the introduction myself? :)

-m (2006-08-16)

You can, or you can write together a suggestion and post it here for comments before cmomitting it which reduces the risk of revertion. Mikademus 13:49, 16 August 2006 (UTC)

All code formatting destroyed

I just noticed that the "minor" edit by Bluemoose destroyed all source code formatting in the entire artile. Is there anyone who would like to start correcting this, or would it be easier to revert the article to the state it was before that edit? Mikademus 10:10, 1 September 2006 (UTC)

Well, being easy to correct, I think a revertion would be innappropriate. Martin 10:14, 1 September 2006 (UTC)

Solved the issue? Object-oriented versus Functional

I think I solved the issue between OO and FP by the opening paragraph I just wrote. The term is used in different senses anyway by different communities, but I believe the fact that is offered by the compiler to help the user in typing too much is the core concept (Well, actually in java one needs to type more, but that's another story), by rising a non-variable element in the grammar to a variable. As said, it's not metaprogramming as it is done within the language and by the compiler and without seeing any source code generated for the user.

I also removed the weighted term small scale generic programming some OO people put there without understanding what parametric polymorphism is and the differences with nominative type systems present in most OO languages (and the cause of this hype of OO generic programming anyway)

-- Carlos Nov 1 2006

Thanks for all the good work; the article is in much better shape now. The organization is just what I proposed above under Cleanup advert tag at 10:40, 2 April 2006 (UTC). Let us hope this will remain stable until the next major improvement. I see a minor (that is, resolvable) issue with the first two introductory paragraph: the emphasis on grammar may make it less general than desirable. See the quotation in my comment referred to above and for example this article, which does not involve linguistic issues beyond the possibility to parameterize.  --Lambiam^Talk 14:36, 1 November 2006 (UTC)

The distinction is better now, thanks Carlos. But the changes need some follow-up copyediting, mainly to clean up some loose or confusing/overtechnical grammar and such. With the broader "definition" now though, it is not at all clear to the reader why macros are to be excluded from generic programming...especially as some macro systems are grammar-aware (m4, Lisp). I do think that the history or timeline part (such as generic programming being introduced with Ada in the 1970s) should be put back into the introduction. Also are there any other functional languages besides Haskell which perhaps deserve some mention here? If not, can we eliminate the empty heading for functional languages (it's best not to have deeply nested section headings without reason). Finally I think we need to be careful about doing original research, not that we've necessarily done that, but we don't want to just make up our own definition of "generic programming" which doesn't match usage of that term out in the real world. Dmeranda 20:50, 1 November 2006 (UTC)

Thanks for the feedback, appreciated. Yes, I made the definition narrower based on my knowledge of OO (imperative programming) and functional programming. I like to find specifics in wikipedia and as I couldn't find them, I read a couple of articles and wrote this. I believe thought that the grammar aspect brings clarity on a concept that might be confused with other programming shortcuts. Probably adding an example will help. Dmeranda: Lisp macros are processed at runtime and therefore don't fall within the definition (That the beauty of it.) Ah, yes, you can do similar things in Forth and probably this is the most extragne case as they happend at compile-time with some bits defined at run-time. And the Forth people don't call them like that. This article is more specific and should be called now Generics (programming). In fact, I find myself very unconfortable with the term generic programming and I don't see it sitting in Programming paradigm along with imperative programming, logic programming, functional programming and the like. A couple of references I found googleing (different from Java) still refer to C++ STL. I do really thing that the OO people overstate their use of the term, which when viewed from a functional perspective is, well, futile.

Bottom line: I think the term should refer to a static process (based on code) by way of a enriched grammar (and sematics, of course) that is not done by another software (no software generators, no pre-processors) but by the compiler itself.

I added the Forth part that then seems to fall in this definition too. Not sure about other programming paradigms. -- Carlos Nov 2 2006

It is getting better, your latest version seems mostly understandable to non-experts (but the part about algebraic type systems, if it is to stay in the introduction, needs either a link or a short explanation). I do have a few comments though. First, I still think it makes sense to pull a little bit of the history of the topic (timelines maybe) up into the introduction. The paragraph on Forth seems to me out of place in the introduction, or is still a bit confusing. I also think that something that's not directly addressed but which probably is another source of confusion is that the idea of generic programming may be different than the actual term "generic programming" in the literature. In general WP articles should document terminology as used (correct or not), not to be creative and try to document what the term should be.

I'm not so confident about the implied assertion that generic programming is necessarily a compile-time concept, although that's the common case. Consider hybrid OO/pseudo-Functional languages like Python, in which nearly everything is runtime, code is generally type-generic by default due to it's duck typing, and which has some advanced features that could be classified as generic programming (and could be considered metaprogramming, but not via code generation). In a way I guess Python could be closer to a Haskell than OO in terms of generic programming...but also, in the python community the term "generic programming" is rarely used although it's certainly practiced routinely. Finally, what do you feel is wrong with "generic programming" (verus "generics")? The former is the historically significant term. - Dmeranda 23:33, 1 November 2006 (UTC)

Yes, I thought about Python and its metaclasses thingy. What happens in Python is that the interpreter, exposes part of its machinery, so you can play with it and do metaprogramming. But then it can be mixed with reflection facilities in Java (there are libraries that allow you to do that as the JVM exposes its internals to whoever is interested). Really not sure where to draw the line. And yes, the part about algebraic types needs more work; however anyone working in haskell-like languages should know what I meant and understand, please leave it there for now. Lot of work required to improve it now that the article leaved the predominant OO approach. -- Carlos Nov 2 2006

Hope you don't mind me changing the section heading of this talk topic to be more descriptive.

Anyway backing away from the small details for the moment, although I like the general approach toward a major cleanup and clarification, I'm not entirely sure the OO versus Functional division is the right one. First, many of the generic features of C++, D, and even Ada are orthogonal to objects. Just because C++ supports OO doesn't mean that you can't write program in it without ever touching objects while still taking advantage of generic programming. So I'm not sure the OO categorization is really the best or that it adds much value (with Java/C# being possible exceptions because everything is so absolutely OO centric that so necessarily are their forms of generics), or for that matter why such a binary categorization, OO vs. Functional, is necessary. However, I do think that much of the material you've added discussing the differing meanings of generic programming; and in particular what is the unspecified generic part that is the important information. For traditional languages these generic parameters are usually data types themselves, while for Haskell they are more like inferred type behaviors (don't know a good phrase to succinctly describe this without going all technical). And you also have other languages, the Pythons and Forths, that really blur the distinctions.

My suggestion would be to take the initial part of the current OO section (but before the language-specific subsections) and add to that some of the general discussion on functional generics; and put that all into it's own section "Different forms of generic programming". Then eliminate a level of section nesting (which is too deep IMHO) by getting rid of the OO and Functional headings, making each specific language a higher level heading. This also makes it easier to browse the article as each language's discussion is more easily distinguished from the others (since level-2 and level-3 headings in WP are hard to tell apart). This would also allow the article's introduction section to remain as non-technical as possible so it's readable by the largest audience, and gives a separate section to start discussing things more technical but before diving into specific languages. If we want to cover approaches which by pedantic technical account are forms of generic programming (Python, Forth, metaprogramming, macros, duck typing, etc), but which in the general literature are almost never described as being "generic programming" or "generics" (by those terms), perhaps we could write a section on "alternatives to generic programming" or something like that? Dmeranda 09:03, 2 November 2006 (UTC)

Thanks, I was thinking in going in the direction you suggested. There is a strong motivation in OO with nominative type systems for doing generics and it's type safety. I was thinking in including this. I would appreciate if you point me to an example in C++ for using templates, not OO motivated. I agree that the OO vs Functional argument doesn't have a place here. generic programming is simply a term used with two senses for different comunities. If we ever heard of another use in another comunity that should be included as well. I will put a motivation for Haskell-like languages and then the proposed general definition may enter (or we can drop it and leave the reader reach her/his own conclusions, if ever interested) -- Carlos Nov 3 2006

Ok, I put a new, motivated and more didactic introduction. The controversial definition is relegated to a secondary role, emphasizing the use of the term. Some work pending, but I believe is coming together. Any contributions in rephrasing or spelling would be much appreciated. -- Carlos Nov 3 2006

Whoa. I don't really like this new introduction, sorry, I thought it had been getting better up to then. I might have spoiled your thinking with my comments. Trying to think like a reader what I immediately see now is a lack of focus or context. There's way too many confusing example code fragments too early, and rather than having the examples support the prose, they seem to be used as a replacement for it. And jumping right into the discussion on type safety is really more of an illustration of the weaknesses of the Java language moreso than providing a clear demonstration or summary of what generic programming is all about at a high introductory level. Type safety, although important to discuss its relation to GP at some point, is a secondary topic. Remember that the introduction (the Wikipedia "section 0") should be succinct (short), clear, descriptive, and broadly accessible. Perhaps you misunderstood my suggestions, although we need to be aware of how the term generic programming is used, it so we as authors can understand the scope of the article since there is no obvious objective definition to guide us, but not to focus on the terminology to the point that the term itself becomes the primary subject of the article. And although we want to be careful about just inventing some definition of GP, I don't want to go to the other extreme and avoid definitions in favor of just examples. Does that make sense? Also, be very careful about writing about motives or judgments in WP, that usually results in poor style or substance. Sorry, I don't want to sound harsh, I do appreciate all the time you've been spending and insight you've provided; I just think this last edit may have been a wrong turn. Are there any other editors following this that might want to provide a fresh thought or two? Dmeranda 05:31, 3 November 2006 (UTC)

You know there is no such concise definition. The term has been used and abused many times. If you search in google for "generic programming X" where X is your favourite language you will get something from someone claiming how to do generic programming on X. I did that for Forth and, yes, there is something out there, despite I said that Forth is generic by default. On the other hand, I am not talking about the weaknesses of Java: any OO language based on a nominative type system has this limitation, which you can overcome adding type variables... and simply the OO people called them generics, which is just, well, an extension to make the things work (and that applies to objects as well to function templates, remember an object is just a wrapping of data and some functions together where the first parameter of those functions is the object). It seems you didn't get this point.

Bottom line, I don't know what to put. The truth is [[4]]

‘Generic’ is an over-used adjective in computing science in general, and in programming languages in particular. Ada has generic packages, Java has generics, Eiffel has generic classes, etc. Usually, the adjective generic is used to describe that a concept allows abstractions over a larger class of entities than was previously possible. However, broadly speaking most uses of generic refer to some form of parametric polymorphism, ad-hoc polymorphism, and/or inheritance.

There are several precise definitions of generic programming, from experts such as Lammel, Wadler, Stepanov, Jarvi, etc. I have added references and links to the three most popular definitions in the section titled "Generic Programming" below. I note that this article is confusing a programming paradigm (generic programming in the sense of Davenport, Gregor, and Stepanov), with programming language features, i.e., templates, SYB, row-polymorphism, etc. thechao (talk) 13:50, 12 February 2009 (UTC)

Of course, these guys haven't done what I said: google with "generic programming X" , for your favourite X. That may throw novel uses of your generic definition... I could add a little bit about generic programming for Haskell-like languages, but I think that I will park this for a while waiting for more feedback. -- Carlos Nov 6 2006

I'm afraid I have to agree with Dmeranda that the new introduction paragraph is not an improvement. It has become a mini article by itself, and does not at all (except for the bold-face title repeat) conform to the Manual of Style, as described in Wikipedia:Lead section. For a "generic" definition, I still think the synopsis quoted above under Cleanup advert tag is a good start.  --Lambiam^Talk 07:20, 7 November 2006 (UTC)

I just returned to this article after a long hiatus and I must admit to being quite dismayed with what has happened to the intro: A long, rambling dissertation without a clear purpuse riddled with neither illustrating nor interesting code snippets. The "new intro" serves no purpose, it confuses the topic, introduces technical aspects too fast and fails in bringing the topic into context as well as in providing a background to it. The intro should not discuss implelemtation-specific technicalities and the mixture of languages and styles is abhorrent. Any language-specific aspecects should be discussed under their own header, not made into a spaghetti vaudeville. The changes should be exiced and the article should be restored to the previous state. Mikademus 22:04, 8 November 2006 (UTC)

Copyright

The "Scrap your boilerplate" Haskell section is copied directly from [5]. Is that legal/has it been authorised/is it too small a section (one para.) to worry about? —Felix the Cassowary 03:23, 5 February 2007 (UTC)

It's certainly bad form in any case, and I removed the text and substituted a link to the web page it was taken from. Someone should write an original section on this work, but I don't have time atm. SparsityProblem 08:06, 5 February 2007 (UTC)

Comment moved from article

This was near the top of the article, commented out:

What about Ruby? It seems like its "duck typing" system and algorithms that use it are a clear use of generics. For example, the Enumerable class doesn't care what it acts on for sorting just as long as it supports the "<=>" operator which does for all classes what C's strcmp() does for strings. Additionally, its metaprogramming is quite applicable as well.

- furrykef (Talk at me) 23:48, 17 March 2007 (UTC)

Failed GA

• The article lacks appropriate inline references
• Some sections are only one sentence or two sentences. These need to be merged or expanded as apporpriate
• The lead is supposed to summarise the article. At the moment, the lead appears to be the abstract theoretical part and the main body appears to be examples. This should not be the case. The theory and the background should have its own section.
• There are separate sections functional and OO languages. Shouldn't there be discussion about the similarities and why there are differences in Generic programming when applied to functional and OO?
• Random thought - does this style have any use in logic programming? Because nothing of this is mentioned.
• Needs more sources badly
• "Generic programming features in other languages" seems out of place. Are those languages not fitting under OO or functional?
• At the start of the functional and OO sections, there are not descriptions of how they work generically in Functional and OO languages, it goes straight to language specific examples. This is a problem. Ideally one should talk about the general way it works in one style, before pointing to the individual details and different nuances of different languages of OO or F.

Blnguyen (bananabucket) 04:28, 23 July 2007 (UTC)

FreePascal entry

I removed the entry about Object/FreePascal. It was inserted above the ADA entry, clearly to advertise the language, and offered nothing of value to the article or discussion. Also, it was relatively badly written and unecyclopedic. Miqademus 12:14, 26 August 2007 (UTC)

Article is POV---please fix!

Article is POV for statically typed languages. It needs to admit that strong, dynamically typed languages get all of the benefits of generic programming transparently, and it needs to provide comparative examples in dynamically typed languages. I'll start, but Python is the only language I know well enough to write about. 66.117.135.137 (talk) 05:19, 30 July 2008 (UTC)

The article is about generic programming, not other mechanisms that might or might not accomplish the same benefits. I'm going to remove the neutrality tag--feel free to put it back in, but be ready to document your claims with reliable sources. 66.127.52.118 (talk) 23:30, 18 April 2009 (UTC)

Generic programming is a style, not a mechanism. If some languages support the style with few or no explicit mechanisms, it is worth noting (assuming it's also worth noting all of these languages with generics mechanisms glued on to the original syntax). Maghnus (talk) 10:36, 29 May 2009 (UTC)

Generic Programming

There are at least several different kinds of generic programming (GP): (1) in the sense of Haskell, which is sometimes called "data-type generic programming" after the scrap-your-boilerplate approach Lammel et al.; (2) in the sense of Ada and C++, which is algorithm-oriented after the Stepanov and Musser approach Stepanov et al., Davenport and Trager Davenport et al., and Gegor, Lumsdaine, Dos Reis, Jarvi, Stroustrup et al. Gregor et al.; and (3) the generics approach, which is bounded parametric polymorphism for imperative and OO languages, a la GJ. Naftalin and Wadler.

If this article is to be balanced and fair, it must separate out language mechanisms (GP kinds (1) and (3)) from programming paradigms (GP kind (2)). Clearly, from the top-level link, this article is supposed to be about programming paradigms. Discussions of templates, template metaprogramming, etc. simply cloud this issue. As such, I find the article entirely suspect, poorly researched, outdated---even given the decades old research---and more than a bit biased.

For instance, where is the description of lifting? Where is the formal definition of concepts? Where is the description of specialization? Algorithm selection? Axiomatic properties of algorithms? The informal description of concepts pioneered by Stepanov and Lee in the STL? What about row-polymorphism ML and its impact on SYB in Haskell? The comparison of intensional polymorphism to two-stage compilation? These are the basic building blocks of the GP paradigm---yet they are not anywhere within the article.

thechao (talk) 13:42, 12 February 2009 (UTC)

I agree with these comments, and think it would be good to reorganize/rewrite the article quite a bit. "Generic" is a vague term used in many different ways, and the best approach is probably to explain the more important ones while making it clear that they don't all mean the same thing. 66.127.52.118 (talk) 00:36, 19 April 2009 (UTC)

There is really only one generic programming concept. It is writing algorithms with knowledge independent of the programming language it is written in. There are spicific generic language constructs in several languages. The concept of generic programming was taught in early programming courses in the 60's. It put forth the idea of programming structure independent of the programming language. That is a program written in assemnly, COBOL, FORTRAN, BASIC etc would have the equivalent structure and perform the same. Generic programming is the understanding of programming algorithms independent of specific languages. The generalization of generic programming is nor so easy explained. A better example might be implementing linked lists. The list operations are independent of the objects on the lists. That is inserting an object into a list can be independent of the object fields as long as the link pointers are in the same position.Steamerandy (talk) 09:45, 9 October 2015 (UTC)

concepts of genericity

It's been obvious for a while that different programming communities use the term "generic" in different ways. The article "Generic Discrimination: Sorting and Partitioning Unshared Data in Linear Time" by Fritz Henglein (ICFP 2008, [ftp://ftp.diku.dk/diku/semantics/papers/D-582.pdf tech report) summarizes the situation on pp. 2-3 of the tech report. While that's not exactly a highly influential paper in the field, I don't think it's making a point of controversy there. I'd like to suggest reorganizing the article somewhat along the lines Henglein describes, particularly with regard to the distinction between polymorphism (what Java and Ada refer to as generics) and polytypism (like C++ templates or Generic Haskell). There is a good article by Jeuring and Hinze (iirc) that explains polytypism that I'll look up in the next few days. It would be worth summarizing its contents in the article. 66.127.52.118 (talk) 00:33, 19 April 2009 (UTC)

article I was thinking of:

• Backhouse, R. and Jansson, P. and Jeuring, J. and Meertens, L. (1999). "Generic Programming --- An Introduction". 1608. Springer-Verlag: 28--115. {{cite journal}}: Cite journal requires |journal= (help); Unknown parameter |booktitle= ignored (help); Unknown parameter |note= ignored (help)CS1 maint: multiple names: authors list (link)

66.127.52.118 (talk) 01:13, 22 April 2009 (UTC)

Yeah, this article is a mess because no commonly accepted definition of "generic programming" exists across languages. So, it's likely to stay that way. Is parametric polymorphism a form of generic programming? It surely does the same job in functional programming languages as generics do in Java, as it's obvious to anyone (well, I see Henglein points it out on page 3). On the other hand C++ templates are "more powerful" as they allow template specialization, i.e. parameter inspection/distinction at instantiation. I'm not sure I understand the definition of "phase distinction" in that paper; e.g. in System F applying a type abstraction is a computation step, but no "case distinction" is possible. This article surely needs some programming language theory perspective because it has been written by practitioners, who unfortunately failed to make the necessary connections or distinctions. But I'm not convinced the definitive theoretical work on which to base this article has appeared...

It's way better if you wrote an article on polytypism, which right now is a redirect to Polymorphs of silicon carbide. Pcap ping 17:21, 25 August 2009 (UTC)

Generic programming as Stepanov and Musser originally intended it is nothing more than the style of programming where you write programs that will work in the most general setting. Writing algorithms and containers that work over multiple types is just one way of making your programs more general. Even simple things like having arguments to functions is facilitating generic programming as it is a parameterization of something that would otherwise be a concrete implementation. This needs to be clarified in the article, and perhaps I will do so when I have some time Peter.alexander.au (talk) 17:35, 18 October 2009 (UTC)

i dont know about generic programming is only templetes in c++ is generic programming —Preceding unsigned comment added by 113.199.188.46 (talk) 05:00, 5 November 2009 (UTC)

.NET arrays

The statement about .NET arrays is wrong, arrays do not implement the IList<T> interface, rather, it's the IEnumerable<T> interface. kazu (talk) 01:28, 17 December 2009 (UTC)

comparison paper

A longer and more recent version of the Garcia/Jarvi/Lumsdaine/Siek/Willcock paper linked further up is at:

http://www.osl.iu.edu/publications/prints/2005/garcia05:_extended_comparing05.pdf

It is a preprint of the one that appeared in J. Functional Programming in 2007. I don't know if the printed version is any different. It compares the generic-programming features of C++, Java, Haskell, ML, and a couple of other languages and it is very informative. The present Wikipedia article is a mess and should probably be rewritten using the above paper as a main source.

FWIW, the paper mentioned a shortcoming in Haskell that was later addressed by Kiselyov, Shan, and Jones:

http://haskell.org/haskellwiki/Simonpj/Talk:FunWithTypeFuns

That describes the "type families" feature found in recent versions of GHC.

66.127.55.192 (talk) 09:21, 3 February 2010 (UTC)

Agda

For later: http://www.seas.upenn.edu/%7Esweirich/ssgip/main.pdf 67.122.209.190 (talk) 08:08, 5 January 2011 (UTC)

Expanded the description of Musser/Stepanov- style generic programming

Clarified the section on Musser/Stepanov-style generic programming with references. As noted in several comments above, this article has degenerated into a list of language comparisons of template/genericity features and has a POV on "generic programming" as meaning simply any programming using genericity. Actually such language technical details and comparisons would be better in a separate article-- perhaps expanding the Template (programming) article. The research line of generic programming espoused by Musser/Stepanov (and one of the original usages of the term) is quite different to this general POV and in fact is independent of particular language-technical details, or indeed compile-time/run-time issues and so it should be clearly distinguished in the article. Other comments here have highlighted other more specific usages of the term "generic programming" in the literature and those could also be distinguished.

Brianbjparker (talk) 02:34, 6 August 2011 (UTC)

I also gave a prose description of the key concepts of Musser/Stepanov generic programming-- actually a small pseudocode example would be clearer. Brianbjparker (talk) —Preceding undated comment added 14:04, 9 August 2011 (UTC).

The added info is good, though it makes the article intro a little bit long. Maybe it could be expanded further, into its own section. 67.117.145.9 (talk) 22:28, 15 February 2012 (UTC)

I have changed the terminology of throughout the article to use "genericity" when talking about a language feature to implement generic types or functions, and "generic programming" when talking about a higher-level programming paradigm, whether Stepanov/Musser or other. Brianbjparker (talk) 07:07, 4 March 2012 (UTC)

unfortunate

This is an excellent article that doesn't meet current Wikipedia referencing standards. Ideogram (talk) 11:16, 27 February 2012 (UTC)

Proposal to separate second section to "Genericity (programming language)"

This article has evolved into two distinct parts-- the first discusses the programming paradigm proper, and the second half is a comparative survey of genericity mechanisms across programming languages. The second half could be separated into a separate article "Genericity (programming language)", with a link from this article. Any comments? Brianbjparker (talk) 00:13, 8 March 2012 (UTC)

Pioneered by Ada in 1983

Generic Programing was pioneered by CLU, seven years before. --Pierre de Lyon (talk) 15:23, 12 June 2012 (UTC)

Parametric polymorphism was pioneered by ML, 10 years before. Cizra (talk) 23:25, 15 December 2012 (UTC)

Code generation and DSL are more generative programming than generic programming

I believe that the section "Code generation" giving examples of adding a domain-specific language is an example of compile-time generative programming, but does not fit withing either of the common definitions of generic programming in the published literature i.e. it is not (type-based) parametric polymorphism nor Stepanov's generic programming. Not every compile-time technique is included in this definition. 218.212.201.235 (talk) 02:23, 25 July 2015 (UTC)

I agree that the example is a bit far out. Would a serialization library which uses compile-time introspection and code generation be a fitting example? --Vladimir (talk) 03:32, 25 July 2015 (UTC)

Not really. Based on the common definitions of generic programming in the literature and referenced in this article, I think that simply code generation, whether compile-time or run-time, is an example of generative programming not generic programming, and so your example above would also be outside the scope of the article IMO (but perhaps suitable for the generative programming article). A key point is the use of parametric polymorphism, i.e. generic types. Otherwise, I think a reliable reference giving a definition of generic programming that is inclusive of such examples should be provided. 218.212.201.235 (talk)

It's easy to find examples of code generation used for achieving generic programming. E.g. go generate being used to "implement" generics in Go or using C macros to achieve a form of generic programming. --Vladimir (talk) 17:21, 25 July 2015 (UTC)

Those examples are using macros or code generation to emulate generic types e.g. to produce generic container classes i.e. they could be given a type theoretic description of their interface. If those languages had built in genericity features then those would be used instead. In fact an example of macros in C being used to emulate type genericity would be in scope. Those examples are fundamentally different to, for example, generating serialization or DSL code. Even in a language with built-in genericity constructs, code generation would be needed to implement those. I just think that if the term "generic programming" is broadened to "anything done at compile-time" in this article, then it becomes a meaningless term which does not match its original usage in the literature. Thus I think that putting such examples in the text is confusing for the reader in defining what generic programming is: type generic functions in a broad sense, or Stepanov's more algebraic definition more specifically. 218.212.201.235 (talk)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Generic programming. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20051225114849/http://lcsd05.cs.tamu.edu:80/papers/dos_reis_et_al.pdf to http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:57, 9 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Generic programming. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf
• Added archive https://web.archive.org/web/20041207211740/http://www.cs.vu.nl/boilerplate/ to http://www.cs.vu.nl/boilerplate/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:07, 12 October 2017 (UTC)

Critique of C++ templates vague

"Templates in C++ lack a lot of features that makes implementing them and using them in a straightforward way often impossible. Instead programmers have to rely on complicated tricks which leads to bloated, hard to understand and hard to maintain code. Current developments in the C++ standards go even further by making heavy use of these tricks and building a lot of new features for templates on them or with them in mind."

What "lot" of features are needed? Why can't they be used in a straightforward way now? How do developments make this worse? GeneCallahan (talk) 06:17, 13 May 2019 (UTC)

Generic procedures in PL/I

I’m not sure how this fits on the spectrum if genericity. PL/I (1964) has “generic procedures”.

DECLARE generic_name GENERIC ( proc1 WHEN ( attributes ), proc2 WHEN ( other attributes ) );

This could, for example, declare “foo” to be “foo_f” fo fooize fixed arguments, “foo_l”, to fooize float arguments, etc., so the programmer could code

CALL foo (some arguments );

and the compiler picks the appropriate procedure. Peter Flass (talk) 02:39, 4 November 2024 (UTC)