From: Walter Bright on
David Abrahams wrote:
> But then, I've never insisted on the ability to redefine
> syntax and tokens, and I don't even believe it's necessary in order to
> achieve the kind of flexibility and power I'm describing.

How would you do it, then?

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

From: Walter Bright on
David Abrahams wrote:
> Scala looks pretty interesting. Did you have a look at it?

I had a brief look at it, thanks for the pointer. Scala has two things
of interest for this discussion:

1) functions with two arguments can be used as infix operators, so I can
int foo(int a, int b);

and use it like:

x = a foo b;

I'm afraid the lack of syntactical redundancy if there were any syntax
errors would make for incomprehensible error messages. An old proposal
for D suggested doing things like:

x = a :foo: b;

to remove the ambiguity. That technically works, but it's just a bit
jarring to the eye. @foo or #foo or $foo are similarly just too ugly for
words. I thought of the old FORTRAN syntax:

x = a .foo. b;

but unfortunately that is even worse, ambiguity-wise.

2) Lazy function argument evaluation. D already has this:
It's an idea I adapted from Lisp <g>. It's pretty cool.

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

From: Walter Bright on
Andrei Alexandrescu (See Website For Email) wrote:
> If a new language is to
> become successful, it better comes up not with what's good in other
> languages, but with some good of its own. Otherwise it will always be
> one step behind.

Consider the following:

Language A has features X,Y.
Language B has features S,T.

X sucks, Y is cool. S sucks, T is cool. So why is a language C that
implements Y,T behind? The combination of Y and T may actually make C a
far more powerful language than A or B, even though it didn't actually
do anything innovative.

Even so, D has already implemented C++ features that exist only as
proposals, such as contract programming, type inference, unicode
support, modules, etc. It has moved ahead of C++ with things like
tuples, scope guard, function literals, lazy arguments, inline
assembler, etc.

All these things make it easier to develop library code. I don't see how
D is a step behind. I don't understand how strings and arrays as core
types sabotages library development.

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

From: Andrei Alexandrescu (See Website For Email) on
Walter Bright wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Walter Bright wrote:
>> I think that's wise, but also it puts the language designer in a
>> follower position, not a leader one. It's like in business - the big
>> money is for those who take a risk. The FedEx idea was the laughing
>> stock in business school. Yet its creator went ahead and implemented it.
>> Now anybody could try starting somebody like FedEx "because it was
>> successful", but probably they're gonna fail.
> Most successful businesses succeed not because they have an innovative
> business plan, but just do the boring basics better than anyone else.
> Walmart comes to mind. Starbucks is another. I think there is huge
> opportunity in the programming language area for a language as
> performance oriented as C++ but with the productivity capabilities of
> Python/Ruby.

Wrong. Both Walmart and Starbucks started with a new business idea. See
"22 immutable laws of branding" by Laura Ries and Al Ries, which happens
to mention _both_ and describes their ideas. McDonalds, too :o).

I, too, think there is an opportunity for a new language combining RAD
with efficiency, but I doubt that the _approach_ to that language is
that of window shopping goodies from the two categories of languages.
I'm not trying to imply D does just and only that, but it looks like it
is certainly driven by that philosophy.

>> In C++, programming with templates can be considered the focal point of
>> interest.
> I agree, but there's the danger that focus has taken away attention that
> should be paid to other basic programming issues. Those other issues may
> be boring, but they're the bread and butter of a successful language.

A beautiful house would be spoiled by some cheap doorknobs. But
doorknobs are just a little part and deserve only this much attention.

>> People use it to implement in user space features that are
>> akin to language features. That's not different, is the exact opposite
>> of making complex a primitive type or adding infix matrix operations to
>> the core. What the heck will I do with that? I use sparse matrices. D's
>> infix operators will be useless to me. Would you please add infix
>> operators for sparse matrices too?
> D doesn't have core matrix features. The whole thing was put off to be
> reevaluated later.

Then don't forget sparse matrices :o|. And triangular matrices :o|. And
band matrices :o|. And...

>>> I am certainly not always right about the utility of various features,
>>> but if you examine D carefully, it is comprised of features that there
>>> is good reason to believe were drivers of success in other languages.
>>> Certainly, the bulk of C++ is in D, and that's sincere flattery. D has
>>> adopted C++'s powerful methods of creating libraries. But D isn't just a
>>> copy of other languages - you've contributed a number of innovative
>>> ideas to it, too, such as scope guard.
>> If you include everything good in C++ but then you take a 180 degrees
>> turn away from its philosophy... that doesn't bode well. (I'm
>> exaggerating here to emphasize my point.)
> Having a philosophy is a good thing, unless one becomes a slave to the
> philosophy rather than the users <g>. One thing I'd like to emphasize is
> D does not take away C++'s UDT capabilities. If anything, it's easier to
> create a UDT in D than in C++.

Becoming the slave of your users entails losing sleep over having too
much power compared to them.

>> The discussion on complex and the built-in matrix operators just
>> bristles my hair. It's just so wrong doing it, doubly wrong to claim
>> it's a good thing to do it, and triply wrong claiming there's no other
>> good way. Everybody would be happier with the admittance: "I didn't know
>> how to do it well, but there is evidence it's useful, so I added it to
>> the language. Sorry."
> I'll admit exactly that. It's true that I know of no way to get the
> basics of strings, arrays, and complex where they need to be and still
> be library features. Many proposals for C++0x have cool features, but
> none of them get us there either.

That might be largely because they have the burden of integrating with
the legacy languages. You may want to look at'em while being relieved of
that burden.

> I'd like to get D to the point where analysts can say: "finally, I can
> ditch the old FORTRAN war horse and move on to a modern language that
> actually caters to my needs." For that to happen, complex and vector
> math support has to be top drawer. What's wrong with C++ complex support
> has already been discussed, it isn't all currently fixable using UDT
> techniques.

Here's exactly where the mistake begins. It isn't all currently fixable
using ___C++'s___ UDT techniques. It would be great if you developed
better UDT techniques. Then instead of saying "look, I can put a complex
in two registers!" you can say "look, I can put any two-floats structure
in two registers!" etc.

> If proper vector/matrix math can be done using UDT's, then
> it'll go that way in D. If it cannot be, then D is faced with having
> inferior support for it, or do it in the core. I can't tell at this
> point what will happen there.
> You are right in one sense - there's a limit to what can be put in the
> core, and that limit isn't very high. UDT's have to pick up the slack.
> But as I said before, strings and arrays are ubiquitous types. Everybody
> uses them, almost as much as they use int's. Therefore, I feel that the
> extra goodies one gets by making them core types is justifiable.
> With complex/vector/matrix operations, I admit that the audience is far
> smaller. It's just that I do have an interest in numerical work, and the
> people doing it have suffered long enough with FORTRAN and the apathy of
> other languages <g>.

And this pretty much summarizes my point: instead of a language bearing
whatever preferences its creator has, it would be better to have a
language streamlined through the innovative permanent participation of a
community. Just like a human language, now that you mentioned it :o).


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

From: Andrei Alexandrescu (See Website For Email) on
Peter Dimov wrote:
> 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.

And that contradicts my statement how?


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