Lambda the Ultimate

Yes, I think this should have been posted in the "Fun" department... :>

Which is the most powerful programming language in the world?

Is this a meaningful question?

Then what is there to dispute, and how would you go about disputing it?

You can argue about the "most powerful" with Frank. I think this is the wrong way to frame the debate.

Dominic just proved that any language is indisputably more powerful than any other, as you cannot dispute this issue meaningfully (*duck*)
So all languages are indisputably equivalent... (*cover*)

I'll begin with a shockingly controversial statement: programming languages vary in power...

I certainly can't. You could talk about turing-complete, but we all know that's meaningless.

I am sure even the C++ guys understand this (wink). It's about language expressiveness. But I think that even in this sense it's problematic to talk in terms of "most powerful language."

Which is the most useful word in the dictionary?

I do think some words are more useful than others. For example, it is hard to write anything meaningful without "the" or "and" or "if".

However, I think their claim is like saying,

"Antidisestablishmentarianism" is the most useful word in the dictionary.

Of course, I would say the most useful words are "variable", "apply", "lambda" and "type". (I am only half-joking...! :)

Without a base vocabulary and a grammar, any word in a base language is worthless. In French (my native language) you can't do much without 2000 or so basic words. Even if you knew the french equivalents to your terms, "variable", "appliquer", "lambda" and "type", without "le", "et", "si" and their ilk, you couldn't form a meaningful sentence.

Altough I must agree that some words are more useful than others. Actually, the French language authorities try to prune the less useful words out of the vocabulary. It's sometimes political, but they try to avoid importing english words into French when a perfectly good word is already in the language, for example.

Without a base vocabulary and a grammar, any word in a base language is worthless.

Of course (though "vocabulary" is redundant). And without a semantics, a grammar is worthless. (Even if the grammar is type 0, and you use an initial semantics—well, that is still a semantics.)

However, my point is that, given the right semantics, some words are more expressive than others, even with a very simple grammar.

For example, strings over the words S, K and I, with the right semantics, suffice to express every computable function. (And, yes, I know one combinator suffices.) Trees over the word "NAND" and a denumerable set of variables suffice to express every logical proposition. And linear combinations of i, j and k suffice to denote every point in space.

... is <http://www.mozart-oz.org.

Maybe that's what they mean, that by using C++ and building systems on it, they can force the rest of the developer community to cater to them. That's certainly a kind of power; it seems to excuse every security vulnerability and bug out there.

It also has effectively denied the users of any other language from reasonable discussion in a systems context.

well, but what about briding approaches that allows you to use C libraries without explicitly writing a binding in C?
Say, in Dylan you can use plain C headers:

define interface
  #include "ctype.h",
    import: {"isalpha" => is-alphabetic?,
	     "isdigit" => is-numeric?},
    map: {"int" => <boolean>};
end interface;

Or in ruby, you can access dynamic libraries via the DL module:

  module LIBC
    extend DL::Importable
    dlload "libc.so.6","libm.so.6"
    extern "int strlen(char*)"
  end

both still require you a little drop in C-land, but you have access to every C lib without thinking a lot about parenthesys.

Well, that is pretty cool. But, what about structures? Its those darn funky C structures (think: TCP/socket stuff) that can make non-C life troublesome. Now, a lot of languages have very complete socket bindings, but it took some work to do so. Unix (posix) like APIs really want to bound to C apps.

well, in ruby:

myStruct = struct [  
   "long foo",
   "short bar",
   "short baz"
  ]

I think Dylan has some similar mechanism too.

Anyway I agree with you that almost everything is just thought for C so all of us using different languages have to obey it's tiranny.

OTOH this is an hint to language/vm/interpreter/compiler designers out there: write it so that you may access C libs withouth needing to compile .c files.
This even fight the common problem of binary bindings for those that does not have a C compiling toolchain (say, most of win32 users).
I plaude the parrot design to include a native calling interface just for this.

Given C++, I would never have to "leave" the language (if you consider it encompassing C) in a traditional Unix/Windows world (i.e. all OS facilities are exposed using the semantics of C/C++).

Not quite. I hack C++ for a living, and I find myself having to "leave" the language all the time. You're right that you don't need to "leave" in order to go down to the level of the machine provided by the OS (which is basically a C virtual machine), but you often have to "leave" C++ to go up to higher levels of abstraction.

We, for example, work with ASN.1-based protocols heavily, so we use a translator which generates C++ code from ASN.1 source. Our software also has a "soft" scripting layer, so we use the scripting language a lot. Sometimes you need to use lex/yacc or similar tools (Boost.Spirit doesn't cut it). On distributed component platforms, you need IDL interface generators. The list goes on.

Now of course any language will require you to do this to some extent. Were I using Haskell with Parsec available, say, I would probably be able to dump yacc and its friends. However, if I were using ASN.1 a lot I would probably always have to use an ASN.1 preprocessor.

Pseudo: ... we use a translator which generates C++ code... Sometimes you need to use lex/yacc or similar tools (Boost.Spirit doesn't cut it)... Were I using Haskell with Parsec available, say, I would probably be able to dump yacc and its friends.

I don't understand. Spirit is an LL(inf) recursive-descent parser generator framework written entirely in C++. In terms of its implementation, it is a parser combinator library just as Parsec is; the difference is that Spirit uses template metaprogramming and operator overloading so that the expression of the grammar in C++ more closely approximates EBNF than is typical in Parsec. And being LL(inf), it is strictly more expressive than yacc's LALR(1). Perhaps you meant to observe that recent versions of Bison implement GLR parsing? Of course, if you are a fan of GLR, you may wish to see <http://www.cs.berkeley.edu/~smcpeak/elkhound, a GLR parser generator that can generate parsers either in C++ or O'Caml, which is very nice.