From: Keith A. Lewis on
In article <J7OdnQNwxpTfT_vYnZ2dnUVZ_uqdnZ2d(a)>,
Walter Bright <walter(a)> wrote:
>So can we agree that the expressiveness and ease of use of the core
>language matters a lot - maybe even more than the ability to redefine
>syntax and tokens?

Sorry for butting in, but I think the answer might be no. Other
factors could be more important.

I think D is great and don't pretend to know the hard won facts
you have learned in the process of creating your language. Gosling
had Sun behind him after he wrote NeWS and gave him the chance to
write Oak.

Forth never had strong corporate backing. You say you enjoy reading
history. Chuck Moore invented Forth. Elizabeth Rather commercialized
it. They are both still around today doing their respective thing.
If you decide to look into this, I'd love to hear your take.

>> And RPN eventually makes my head hurt :)
>RPN might make your head hurt, but some C++ TMP code gives me an
>aneuryism <g>.

I'm probably going to get modded out for mentioning D, Oak, (Java
implicitly), and Forth. I think C++ is the eighth wonder of the
world. The amount of intellectual manpower that went into its
creation is similar to the amount of physical manpower that must
have been involved in the Great Pyramid of Giza. The (arti)fact is
that it is very difficult to become a good C++ programmer.

You and Gosling might be the last two people on the planet that
can write a major language singlehandedly. C++ is going to be around
for a long time, and D seems to be a real improvement, but Microsoft
learned their lesson from Java. C# is their reply, and they have
the money to make it happen.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Alf P. Steinbach on
* Andrei Alexandrescu (See Website For Email):
> Walter Bright wrote:
>> For another imponderable, why do reusable Java libraries sprout
>> everywhere you look, but reusable C++ libraries seem to follow a more
>> tortured path? Is there something about C++ that makes it difficult to
>> write libraries?
> We discussed this and came to the conclusion that garbage collection is
> the first thing.

I haven't seen that discussion (I think), but garbage collection would
be somewhere at the bottom of my list: it just isn't important here.

At the top of the list thrones the practical problem of /building/ a C++
library. Arcane tools, no standards, fixing code here & there to make
it compile with your compiler(s). It's next to impossible for a novice
to download, install and use a typical C++ library, without a cookbook
of instructions for that particular library version, client OS &
toolchain. Of course the situation improves when the library is mostly
header files, like Loki and Boost. But restricting libraries to
header-file-only libraries would, well, seriously restrict libraries.

At the second place the practical problem of /using/ a C++ library,
because it's not unusual that it will only work with e.g. some specific
version of the compiler's run time library. Or perhaps it uses wide
streams and so won't compile with g++ under Windows. And what then?

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Bob Bell wrote:
> Walter Bright wrote:
>> And why do users often write their apps in Python, and use C++ just for
>> the bottlenecks?
> Because they don't know what they're doing? ;-)

LOL! But it doesn't pay to assume everyone who disagrees with one is an

> Seriously, don't assume that this works just because developers feel
> good when they do it. I know of a major project at my previous company
> that was written that way, and it turned out to be a disaster. The
> developers loved working on it, though -- the fact that they could make
> a small correction and see it running in seconds gave them a great
> feeling of power and control. They all felt extremely productive, that
> Python made the project go very smoothly. The failed to notice several
> factors:

Google apparently uses Python in the manner I suggest. I don't think
Google is populated by people who are so in love with their own code
they forget all about the customer.

> 1) their gains in productivity were offset by additional problems that
> would not be present in a one-language-only project (e.g., language
> boundary issues)
> 2) It turns out that Python has large-scale development issues that
> aren't apparent when knocking out a simple script (e.g., they had
> numerous, repeated problems making sure that the versions of all their
> modules were in sync)
> 3) Python's "rapid development" (i.e., the absence of a compiler)
> optimizes the wrong bottleneck; waiting for the compiler is not what
> makes a complex program take a long time to write

I agree with your points 1..3.

> The issues were not related to competence; the engineers on the project
> were all extremely competent. But the end result is that it took over
> two years to get the program done -- about what it would have taken to
> get it done with C++ alone.

Trying to mix languages on a project is something born of desperation,
not craft. So something about Python is proving irresistably attractive.

>> Is there a way I can combine the productivity of Python
>> and Ruby with the performance of C++ with Java's ease of library
>> creation? I like to think there is, and I want to find that sweet spot.
> What makes Python feel so productive? No compile-link phase and the
> availability of a wide variety of libraries.

Python is a much younger language than C++, yet has the wider variety of
libraries. I think that's a big indicator that the productivity of
Python is not just faster compiles.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Dave Harris on
belvis(a) (Bob Bell) wrote (abridged):
> What makes Python feel so productive? No compile-link phase and the
> availability of a wide variety of libraries.

Also the lack of manifest type declarations. C++ pays a heavy cost for its
static type checking.

Also the automated garbage collection.

You mention libraries. A good language is a language which facilitates the
expression of good libraries. If Python has more productive libraries than
C++, that's an indication that the language itself has productivity

-- Dave Harris, Nottingham, UK.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Peter Dimov on
Andrei Alexandrescu (See Website For Email) wrote:

> That's simply wrong. Java does not check thread safety statically, yet
> is able to define behavior of even incorrect multithreaded code.

It does on a physical level (long and double aside), but not on a
logical level. An object invariant can easily be broken by a data race.
The behavior from this point onwards is defined but makes no sense.
This decision is correct for safety reasons, but doesn't offer many
other benefits.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]