Generic programming is a way of writing code, not a thing that your language supports or you can't do it. I can write perfectly re-usable C code that is also very efficient by relying on the pre-processor to customise the code to the exact types and conditionals required for the situation at hand.

It's a bit like saying you can't write functional code unless you use a functional language.

Firstly, using the preprocessor will mean there is code duplication, even if it is not necessary. Secondly, once you are using the preprocessor to do generic stuff, you have probably thrown type-safety away.

That's not to say you can't write C in a generic way, but "generic programming" means something specific to computer scientists and has certain prerequisites.

And you can't write functional code without a functional language, without building a functional language on top of your language (which may not even be possible, e.g. you can do functional-ish stuff in C because of function pointers. Without them, you'd be stuffed.)

You can write functional code in a "non functional language", if by functional language you mean "Haskell, ML or Scala". But you need certain features like function pointers to do it, and in that sense you do need a functional language. Same for generic programming - you need certain features.

Function pointers are very far from sufficient because you can't define new functions at runtime, since you can't nest functions or define anonymous ones. That means your functions are not first class citizen of your language and some common functional programming techniques are impossible to use in a clear way.

You can't do that for example :

    def make_adder(num_1):
        def adder(num_2):
            return num_1 + num 2
        return adder

Yes. Generally you then start cheating by passing around a function pointer and a void* that is the first argument of the function, i.e. doing closure conversion yourself. You can hide this with some macros and get close to having a functional language, but it's ugly and tedious (Cfront anyone?) Also, what I'm describing here is more similar to object orientation than functional programming. It's worth remembering the following koan though:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

-- Anton van Straaten

I downvoted you because i think you're flat out wrong, both on the functional account and on the generic account. Although i'm curious, how would you do generic programming in C a language in which you can't even define a generic list type without renouncing to static typing ?

You do realise that the first version of the C++ compiler was a pre-processor for the C compiler ? And that in the end all this stuff outputs assembly language ?

As for functional programming someone just released a lisp for PHP. That doesn't mean it's the 'right' way to do stuff, but it can be done, and programming 'generically' was done for years before someone took the time to produce a language for it. I've written piles of code that would write programs (usually C) to avoid having to write the same kind of code with slight variations.

In the end all this stuff is Turing complete, so if you can do something in one language, by simple reasoning you can figure out that you can do that trick in any other by implementing a (subset of) the former.

Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. -- Alan Perlis, Epigrams on Programming

Why does Generic Programming require static types?

The type-parametric functions are inherently a feature of a static-typing system...so I guess "by definition" would be the answer. At least that's what the wikipedia entry would lead me to believe.

http://en.wikipedia.org/wiki/Generic_programming

See also: http://en.wikipedia.org/wiki/Type_polymorphism#Parametric_po...

From the OP's definition, it needs static types so it can be compiled efficiently. You can do it dynamically (e.g. Ruby) but you can't do it as fast in general.

Additionally, generic programming is a computer science concept, and those types tend to prefer static-typing for safety reasons. They're probably not strictly necessary if you ignore efficiency.

Dynamic typing (ala Scheme or Python) gives you generic programming for free, but it's less efficient.