This is a difficult thing to answer conclusively. Different languages have their strengths and their weaknesses, different places where they're flexible and fixed. It also depends a lot on which programming model (imperative/object-oriented, functional, logical) you're most accustomed to, and what you define as flexibility. (For the sake of simplicity, I excluse any platform-specific language from the running.)

For object-oriented I'd have to say it's Smalltalk. All inheritance-based OO concepts can be implemented in terms of aggregation, and having run-time mutability is a very powerful advantage.

For imperative, it's a much more difficult choice. PERL is incredibly flexible in the same ways LISP and Scheme are, but I personally feel queasy when it comes to any programming language designed with a natural language mindset. Python would be a better choice, except that really it's object-oriented, and I have major issues with any language which is whitespace-sensitive. And really, anything you can do in PERL or Python you can do in C as well (it'll just be more difficult). So really, this choice boils down to preference.

Functional is easy... Scheme. LISP with a simplified syntax, just enough imperative constructs to make it workable, and none of the crappy wannabe-objects which have slowly sneaked their way into the current implementations of Common LISP. It's also nice to have the scoping rules cleaned up and disambiguated.

Logical is another no-brainer. Prolog. It's inherently parallelizable, has clear and simple resolution and unification rules (with the notable exception of the cut operator, which I still don't really understand), and aside from a few gotchas, it's quite robust for everything from databases to expert systems to problem solvers. And, if speed is what you want, Sicstus can compile, and it's not that hard to use Prolog to prototype at an algorithmic level and then convert it to something like C++ for production uses.

That said, I use C++ for almost everything, because of the set of requirements I have for any language: it must be object-oriented, relatively platform-independent (as long as that platform is UNIX, anyway), and fast. It'd be nice if C++ had a sane object model (not having a base object really cramps its style, and leads to nasty hacks such as templates), and I've still yet to see a reasonable justification to multiple inheritance and all the crap that adds to the language (particularly at the implementation level), and it'd be nice to have some of the nice features of Turbo Pascal/Delphi (interface being encapsulated in the compiled object file, each library having its own implicit namespace, having nested functions, etc.), but overall, C++ is the language which sucks least for my needs. Oh, and although there's no real runtime mutability, you can simulate aggregation through abstract virtual methods, so at least it's got that going for it...

assembly would by definition be THE most flexible programming language for any given architecture because the limits of the language represent the limits of the architecture you're using.

To name a language in common modern usage like everyone else has - I'd have to say Ruby. It combines a clean, elegant syntax with a REAL object system a-la smalltalk and this concept of blocks from CLU resulting in a tool that purrs like a kitten but roars like a lion.

One readily demonstrable aspect of Ruby's flexibility is its dynamism. Any class can be modified/augmented at any time unless it has been explicitly locked (or frozen in Ruby parlance). So if for instance the suits in charge of the statistics app you're developing decide on a whim that "XML is GOOD" and move to web-based output, you can simply augment Object (The common ancestor of every Ruby object - Java uses the same convention like so:

class Object
  def to_s
    # Code to spew XML tags for each property

And that's it, now whenever any of your objects are asked to return a string (e.g. they're being printed) they'll do the right thing.

Log in or registerto write something here or to contact authors.