I think maybe some clarification is needed. When writing exploits your major concern is going to be the target and the environment in which it will be used. The target is generally going to dictate what the code actually does (ie. the how the hack is done and the payload) while the environment will dictate how it does it. As an example, the lsas exploit I linked earlier has a bunch of hex that is the actual exploit since it is the data that is sent to the service in such a way that it will cause it to react in the way that you want. The target (in this case the lsas service) dictates what you can do. The environment will determine how you do it. This specific example is coded in C which means it is going to have to be compiled in order to run. Compiling code is system dependent meaning if it is going to run on a linux box you cannot use code compiled for a windows system. This comes into play because sometimes you run code on your local system and sometimes you run code on the target system. If you are running code on your local system you have almost complete control of the coding language you will use so it is more a matter of personal preference. If you are putting together code that will be executed on a target system then the language you use is controlled by the target environment. For example, if my target is a windows box I am more likely to write something in C, compile it for a windows box, then move it over and use it on the target. This is done because I can't expect most windows systems to have built in compilers or scripting support. If the target system is a *ix box, then I'm more likely to put together my exploit in perl or uncompiled C because most *ix systems will have perl (or python and sometimes ruby) support and gcc (c compiler) support bundled into the kernel.
CISSP, CISM, CISA, GCIH, GREM, CEH, HMFIC, KTHXBIROFLCOPTER