Talk:Generic programming

message: 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)
replies: text: 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)
thread_title:  Dynamically-typed Languages 

message: I think what the current article describes is NOT template metaprogramming. see .
-- 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)
thread_title:  Is this template metaprogramming? 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Lisp (CLOS) 

message: 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)
thread_title:  Generic programming in Haskell 

message: 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)
replies: text: 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)
replies: text: 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 , 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title: D

message: 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)
thread_title:  Introduction 

message: 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)
replies: text: Well, being easy to correct, I think a revertion would be innappropriate. Martin 10:14, 1 September 2006 (UTC)
thread_title:  All code formatting destroyed 

message: The "Scrap your boilerplate" Haskell section is copied directly from . 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)
replies: text: 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)
thread_title:  Copyright 

message: 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)
thread_title:  Comment moved from article 

message: *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)
thread_title:  Failed GA 

message: 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)
thread_title: FreePascal entry

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Article is POV---please fix! 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Generic Programming 

message: 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)
thread_title:  .NET arrays 

message: 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)
thread_title:  comparison paper 

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

message: 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)
replies: text: 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)
thread_title:  Expanded the description of Musser/Stepanov- style generic programming 

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

message: 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)
thread_title:  Proposal to separate second section to "Genericity (programming language)"

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

message: 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.
Cheers.—InternetArchiveBot (Report bug) 04:57, 9 January 2017 (UTC)
thread_title:  External links modified 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 17:07, 12 October 2017 (UTC)
thread_title:  External links modified 

message: "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)
thread_title:  Critique of C++ templates vague