The correct answer is Java.
Piet, of course.
Microsoft did not invent object serialization. Processes on Unix-like environments have been piping structured data to each other for eons.
Powershell is still pretty cool, though.
For os scripting: bash + sed + awk. I would pick perl but too often I work on systems where code dependencies and imported modules create problems, so it’s just not reliable or friendly to set up.
For problem solving, analysis and design: scheme (more powerful & less restrictive imo than python). Especially for putting together simple domain specific languages, and recording structures and plans.
For fast ms windows development: C# (.Net) It’s edging out Java in my toolbox simply for the sake of Visual Studio & extension methods. It does put alot of stress on Enumerables and it encourages developers to use them even when they aren’t the right choice (LINQ anyone?). I hate it however for server side development, but that might be a Java bias.
For enterprise applications: Java + ant + J2EE (Preferred Container: JBoss). It’s flexible, multi-modeled, efficient by default, and easy to manage & maintain. Also if it doesn’t do something the way you want it to, you implement an interface and change an xml file and bam, now it does. C# .Net pretends to do this, and then fails horribly. Also I find the J2EE model for handling requests to be far far superior, I don’t understand why MS wouldn’t use a decorator model for request handling, it seems dumb to me.
This evening it’s Common Lisp. Tomorrow or next week it might be Haskell. Maybe in a few months it will be Prolog or Smalltalk, if I can ever get around to learning those languages like I want to.
Also known as a struct. 
I have no issue with the world standardizing on a single ABI. But that would have been as simple as saying, dammit, let’s just settle on an ABI.
COBOL.
Much as people don’t like it, it is the language the world runs on. Your electric bill, your car payments, your bank statement, your paycheck, your Social Security forms, your tax forms, your credit card statement, your student loan, your student class reservations, almost anything important & critical to your safety & survival runs through a COBOL program (and probably IMS or DB2 database).
And if you define best the way nature & evolution do (‘survival’), COBOL is best there too. Ii celebrated it’s 50th birthday this summer, and is still going strong. (And some of the first COBOL programs from back then still compile and run – just on a Intel chip under Windows 7, instead of on a UNIVAC II.) A year ago, many of those languages mentioned would have been different ones, but they have all been replaced by more fashionable ones. And a year from now, newer ones will replace them. But COBOL will still be around, still doing the majority of the transactions.
Dinosaurs forever!
I’m extremely skeptical about the supposed ubiquity of COBOL. I know it has its niche, but the idea that every major transactional or batch-job system in the Universe is implemented in ancient COBOL code that was punched on stacks of papyrus by the Pharoah Hopper herself seems to approach urban legend status year after year.
More software has been written in the past ten years than the previous forty combined. There are extant legacy systems in the world, but there are enormous transactional systems that date back just a few years in common use, too. Were these implemented in COBOL? Extremely unlikely. You don’t see many ads for fresh-out-of-college COBOL programmers to work at startups.
I guess the CTS isn’t doing much that a thoroughly-defined native ABI couldn’t do.
Most of the benefits are all a bit nebulous at the moment, I suppose. Architecture-agnosticism could be fantastic, but isn’t used much. OS-agnosticism could be fantastic (and a native ABI can’t be OS-agnostic), but isn’t used much. An OS that has no context switching (a bytecode can be verified as not referencing anything it shouldn’t) could be fantastically fast, but such OSes are mere research projects.
But… the benefit to vastly simplifying the design of new languages (not having to worry about many compilation details) is useful today, and I think it makes up for a lot.
There’s probably other benefits to the CTS that I’m not thinking of.
Well, the point is that when you invoke the command in the shell the structured data is automatically rendered human-readable. And when you pipe that data to a different command, the program doesn’t have to be designed to understand it. (Eg, the ‘sort’ command can work with all kinds of inputs.) That’s really what makes it wholly different.
Haskell is mine as well, though I’m not sure I have anything better to say about why.
Java is quite clearly inferior to Haskell, and virtually every other programming language in the world, in every possible sense.
I like Forth best.
It is by far the simplest, except for Assembly, in the sense of understanding what the computer is doing. There is a book by C. H. Ting about eForth that is about 3/8" thick. The early chapters discuss the language’s foundations, including some Assembly definitions as you would enter them into MASM. The book then shifts to defining additional Forth words, in Forth, based on the earlier foundation. By the end of the book you have the entire Forth system. Following along with the book and your PC, you will have actually created the Forth system, from scratch, without any downloads or disks. You even understand where the components reside in memory for the Forth system. There isn’t anything hidden about any of it.
You can run the Forth system as an application, or you can have Forth run the entire computer as its operating system and command interpreter. There are even a few microprocessors that natively run Forth as their assembly language.
In learning Forth, the classic book “Starting Forth” by Leo Brodie features a two headed Pterodactyl. There’s nothing about any other language I have come across that gives nearly the level of understanding as studying the Forth Outer Interpreter and Inner Interpreter, and the most wonderful and Zenlike moment blossoms inside your head when you discover that the Inner Interpreter is actually just the microprocessor’s opcode for a Return instruction. In fact, Zen is a popular simple version of Forth.
Pygmy is an especially small version that is perfectly workable. It is only 15 kilobytes in size. A bigger version is SwiftForth, a professional system for Windows applications that is supported by an active user community.
Forth is the cleverest thing I think I have ever understood. I am comparing it to APL, Algol, Basic, C, C++, C#, Fortran, Java, Lisp, Mathematica, Modula-2, Pascal, SAS, Scheme, and others.
By the way, I just don’t get Scheme at all. The whole thing is written in goddam parentheses, which I hear good Scheme programmers learn to ignore. The language was originally created for generating Fibonacci sequences, and since they use this problem as a teaching example in every single book, the language is essentially fully used and exhausted by the time you finish learning it. It’s the more theoretical or abstract counterpart to Lisp, as if Lisp were the nuts-and-bolts general tool everybody grabs first, like the pliers of programming.
on paper, C++.
IRL, Perl!
DNA: too hard to read! 
Object Pascal, followed by Objective-C of course! Or maybe the other way around. Unfortunately I’ve been using too much PHP and SQL and Python lately, none of which I’m really fond of.
I concur. Scheme was a nightmare for me. I just don’t get functional languages at all. I guess that one of my weaknesses.
I would have said Haskell too if, after dicking with it for 20 years now, I could do anything more than “Hello World” with it.
That’s the problem with Haskell and Lisp. Beautiful and powerful languages but not enough of an ecosystem around them: vast libraries, intelligent IDEs, refactoring tools, etc.
Just yesterday, I wanted to create a menu system for play 24-bit wav files while a background tasks also does frequency analysis with Fourier Transform. Using F# (and C#), leveraging the vast libraries in .NET and Codeplex makes it amost a trivial exercise of gluing components together. In Lisp/Haskell, comparable libraries of functionality are non-existent and I’d have to do many of these things myself.