To my knowledge, all modern imperative programming languages support recursion in the sense that a procedure can call itself. This was not always the case, but I cannot find any hard facts with a quick Google search. So my question is:
Which languages did not support recursion right from the start and when was that support added?
I'm not sure COBOL does (it certainly didn't at one time), but I can't quite imagine anybody caring much either.
Fortran has since Fortran 90, but requires that you use the recursive keyword to tell it that a subroutine is recursive.
PL/I was pretty much the same -- recursion was supported, but you had to explicitly tell it what procedures were recursive.
I doubt there are many more than that though. When you get down to it, prohibiting recursion was mostly something IBM did in their language designs, for the simple reason that IBM (360/370/3090/...) mainframes don't support a stack in hardware. When most languages came from IBM, they mostly prohibited recursion. Now that they all come from other places, recursion is always allowed (though I should add that a few other machines, notably the original Cray 1, didn't have hardware support for a stack either).
Wikipedia says:
Early languages like Fortran did not initially support recursion because variables were statically allocated, as well as the location for the return address.
http://en.wikipedia.org/wiki/Subroutine#Local_variables.2C_recursion_and_re-entrancy
FORTRAN 77 does not allow recursion, Fortran 90 does, (recursive routines must be explicitly declared so).
Most FORTRAN 77 compilers allow recursion, some (e.g. DEC) require using a compiler option (see compiler options chapter). The GNU g77, which conforms strictly to the Fortran 77 standard, doesn't allow recursion at all.
The OpenCL programming language does not support recursion. (see section 6.8 of the OpenCL Spec)
The current motivation for that is a) a lack of space for deep stacks b) a desire to know, statically, the total required allocations in order to optimize for performance in the presence of large register sets and extensive in-lining.
This may well apply to other GPU programming languages, e.g. shader languages.
Some c compilers for small microcontrollers don't support recursion, presumably because they have an extremely limited stack size.
BASIC, in the days of line-numbers, tended to have poor recursion support. Many (all?) BASICs of that time supported nested gosub calls, but did not support an easy way of passing parameters or return values in a way that made it useful to self-call.
Many early computers had problems with recursion, because they used call instructions that wrote the return address into the beginning of the routine called (PDP8, the IAS family of machines, probably more architectures I am unfamiliar with), usually in such a way that it was the machine code for "Jump to the instruction after the one that called the routine".
It depends on what you mean by "support". To support recursion you need a stack where to re-instantiate local variables at every re-entrance.
Even if the language does not have the concept of local variables, if it has the concept of "subroutine" and has a way to manage an indexing between identical variables (a.k.a. array) you can increment / decrement a global index upon every enter / exit of a function and access through it a member of one or more array.
I don't know if this can be called "support". The facts are that I wrote recursive function with the ZX-Spectrum BASIC, as I did it in Fortran77 as in COBOL ... always with that trick.
Assembly language doesn't directly support recursion - you have to "do it yourself", typically by pushing parameters onto the machine stack.
