Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I do programming in an academic setting at the moment, so I can use whatever I want. I'm using the boost graph library for a few things, and I'm wondering whether investing effort in understanding GP more deeply is worth it.

I'm curious - is generic programming (GP) used much in industry? My guess is that most programmers are much more comfortable with OOP or are using languages that don't emphasize or support GP, so that outside of calling STL data structures/functions in C++, my impression is that GP isn't used all that frequently in practice. But, being outside industry at the moment, it'd be nice to hear from practitioners on this.

(as I'm writing this, I see that generic-programming isn't even a valid tag!)

share|improve this question
    
Tag distribution on StackOverflow is probably much more useful as statistical evidence than the one over here. See stackoverflow.com/questions/tagged/generic-programming, stackoverflow.com/questions/tagged/generics –  Péter Török Jul 25 '11 at 16:46

3 Answers 3

up vote 7 down vote accepted

I'm curious - is generic programming (GP) used much in industry?

It's really widely dependent on the context of the team and the project.

For example, in video games, often the code is the "simplest" possible (and even sometimes too simple) but in large architectures. That's because game developers have a lot of problems to fix and don't want to bother with meta programming (that is a separate very abstract and hard to grasp language inside C++).

At the same time, basic usage of templates are common even in those shops and you can see some template-based optimizations in some very specific functions of some engines.

But in game dev, most people will just avoid any metaprogramming.

Now, on the other extreme side, some really complex or heavy processing applications, that are not common, requires some kind of heavy metaprogramming because of performance and flexibility (at compile time) requirements that are not common. I'm working in one right now.

It's not common but it exists and some niche domains (in some scientific or number-crunching embedded contexts) does require people knowing a lot about metaprogramming or wishing to learn.

In the middle, most people will just use meta-proggramming as "client", not as "designer". Most meta-programming code are bundled in libraries because libraries are tools for code and what is better than a library that can adapt to the custom types you've been working with until now?

Boost (http://boost.org) is a set of libraries, some being made of heavy metaprogramming black magic, and are used in a lot of C++ shops as "STL++", an extension of the STL (and it is). Not every shop does use it for several reason, like compiler compatibility (some boost libraries can make your compiler beg pardon for every time he did hurt your feeling...) and more often because some developers don't like not being able to understand how a tool works inside (try to understand Boost.Spirit...)

Whatever the companies you will work for, some will use this paradigm, some will less or not at all or even forbid them.

There is no consensus because nobody have the same needs, context or team.

But still, obviously, it is used. Maybe ask who use boost on their mailing list to have more real-world examples?

share|improve this answer
1  
+1 for client vs. designer. In my experience, few enough developers understand their implementation that it doesn't make sense to create new generic code in an application unless it makes a large improvement in maintainability. Libraries designed for wide reuse fall under that condition much more frequently than individual applications. –  Karl Bielefeldt Jul 25 '11 at 17:53
    
Thanks for the detailed answer. I'm a fan of Boost myself and considering whether to dig into BGL, which requires substantially more GP knowledge than other Boost libraries is what led me to ask this. Your comment about the game development world is pretty intriguing. I'm amazed at the development feats of modern games and it's interesting to hear that they're probably insulated from newer programming methodologies rather than at the forefront of them. –  bd1 Jul 26 '11 at 16:07
    
Well, game developers are managing high order of complexity just by having to architecture games concepts. Adding meta instructions just complexify everything so it have to be really well justified. The other thing is that a lot of game devs works on consoles that are very specific hardware with very specific compilers that don't allow everything boost tries to do (for example, no exception or no multiple inheritance or not working correctly from the doc of the compiler (true story)). So, there are good reasons. –  Klaim Jul 26 '11 at 20:57

I'm curious - is generic programming (GP) used much in industry?

Generic programming, academically called parametric polymorphism, is very often used in the fields. At my company, we use it mostly to build up type independent editors for data, regardless of their kind. You just don't need it as often as other features, but it's definitely a feature I wouldn't want to miss. You use it when a behaviour fits a large number of types. It's a clear sign that you need generics when you find yourself writing the same code multiple times for different types.

My guess is that most programmers are much more comfortable with OOP or are using languages that don't emphasize or support GP, so that outside of calling STL data structures/functions in C++, my impression is that GP isn't used all that frequently in practice.

At least from my experience, your point of view is wrong. OOP and generic programming are not mutually exclusive. In fact, you should use the synergy effects of combining them. Like I stated before, the reason you don't see it appear as frequently as other techniques is because you don't need it that often. But it's a strong feature to have and greatly helps you keeping your code DRY. Which languages don't really emphasize the support of GP in high-leveling programming? 3 of 5 languages of the Tiobe Top 5 support generics/templates. And PHP is dynamically typed so it doesn't really need them. So what?

share|improve this answer
    
point taken, I didn't mean imply that OOP and GP is an either/or choice. However, many of the projects I've seen seem to be strictly OOP in Java. I think more recent versions of Java supports GP, but what fraction of Java programmers really use that functionality? As I said, I'm not working in industry and my perspective may well be skewed, which is why I asked the question. –  bd1 Jul 25 '11 at 17:00
    
@bd1: Older applications that were written before Java supported generics, or before a particular toolset supported that version of Java will not have generics, and the developers may continue to avoid generics on that particular project, to keep the code consistent. I've seen that, and it varies by project and by the developers. Any projects I've seen that were started after support for Java generics was widespread tend to use them often, when appropriate. –  FrustratedWithFormsDesigner Jul 25 '11 at 17:30
    
@FrustratedWithFormsDesigner: Generics in Java are completely different from C++ templates. Java generics are 100% pure syntactic sugar, and do not support meta-programming. –  kevin cline Jul 25 '11 at 23:47

C++ templates are used widely for stuff different than containers - at least in my problem domain (quantitative finance). I'd even venture to say that it is sometimes used too often, for purposes where plain old virtual functions would be enough (and would not increase the compilation time so much).

People use it to avoid code duplication and to achieve compile-time polymorphism (without virtual dispatch).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.