## The C++ Source Journal

C++ [is] indisputably the most powerful programming language in the world. For reasons understood by many, it has, however, become a very complex language, and many a novice has followed after the siren song of lesser languages.

So is launched The C++ Source, the authoritative voice for the C++ community on the web. The board of editors is a veritable Who's Who of C++. Articles are peer-reviewed. There is not much content yet, but it looks like they offer live feeds. The journal's premiere article, "The Spirit of C," offers a potted history of C.

Like BCPL, B was a typeless language with a rich set of operations on machine words... How well does B embody The Spirit [of C]? Almost perfectly, in my opinion. "Trust the programmer" and "Don't prevent the programmer from doing what needs to be done" are obvious characteristics of a typeless language. [Meanwhile, however, the] C++ language is very nearly completely type-safe, which is a good thing, as its type system is arguably the most complex of any language.

Put that in your pipe and smoke it.

## Comment viewing options

### Indisputably?

Why would someone use the word "indisputably" when making a claim that people are sure to dispute?

### Fun department?

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

### J'accuse!

C++ [is] indisputably the most powerful programming language in the world.

I dispute it.

### OK, then

Which is the most powerful programming language in the world?

### Wait a sec

Which is the most powerful programming language in the world?

Is this a meaningful question?

### If it isn't

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

### That's my point

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

### It's fun after all

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*)

### Define "powerful".

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

### Obviously it's not Turing completeness

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."

### Counter-question

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...! :)

### None of them, of course.

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 a

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.

### My two cents

The most powerful (programming) language in the world is the one that:

- allows you to quickly understand the abstractions of others, expressed within that language.

But abstractions used to express programs (recursion, means of decomposition, ...) have to be learnt, and applied, and you wind up expressing your mental model in terms of those abstractions, so a richer library of abstractions would suggest a more powerful programming language. Except, of course, that you need to know all of these abstractions well to understand programs written by other people in that language.

So... the most powerful programming language is the one containing a small selection of powerful abstractions easily understood and applied by all proficient users of that language?

Not that I can suggest a candidate!

### Definition of "Power"

Perhaps the definition of power being used in the Chuck Allison quote relates to the capability of the language to be used for all facets of programming (whether it makes sense to or not ;-)

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++).

While a lot of languages are more expressive and offer better abstraction, you never have to import/translate OS and library facility access with C/C++.

Now, if the native OS was written in, say, Lisp, Forth, ML, etc then I wouldn't have to drop down into C/C++ to get my stuff done.

It's perhaps a sad state of affairs, but when using non-C/C++ languages I always find (at least) one library/OS facility that is lacking or requires me to drop down into C/C++ to get at its full capability. Be it Perl, Tcl, Ruby or various Lisps, there are still holes in the bindings...

### Power to disenfranchise?

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

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
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.

### briding and binding

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 =

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

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.

### Parsing Tool Choice

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.

But I remain curious: in what sense does Spirit "not cut it," especially relative to yacc?

### Glass houses and ivory towers

Ehud: ...it is easy to get carried away, and forget that choosing a programming language...is...often very much dependent on the platform for which the software is developed.

I agree that platform issues are part of the language sufficiency equation. However C++ aficionados like to argue, as here, from intrinsic language merits and, ah, spirits, despite the most complete platform support of probably any language. It is not just the C++ experts who talk that way.

One often hears from C++ boosters that other languages are elitist or academic. One of the take-home points here is that C++ folks sometimes live in glass houses and ivory towers of their own.

However I look forward to the journal content. These really are the C++ pros, and it is a powerful language, of course.